Modeling misunderstanding
Going out of general design misunderstandings, moving towards success
Author: Scott Ambler (scott.ambler@ronin-intl.com)
Original: http://www.sdmagazine.com/documents/s=844/sdm0108k/0108k.htm
Translation: This article has not been contemplated by the author, only practice.
Whether you follow the weight-level approach, such as Enterprise Unified Process (EUP), or a lightweight development process, such as Extreme Programming (XP), modeling is indispensable in software development. But unfortunately, it is full of falsehoods and ingles. This comes from all aspects, there is a research from the theor's wrong, decades, cultural deposits in the field of information technology, software tool developers, a semi-market propaganda and the standard of Object Management Group (OMG) and IEEE. This month, I want to reveal the misunderstanding in the model, pointing out the truth of its corresponding facts.
Misunderstanding 1: Modeling is equal to writing documents
This is likely to be one of the most destructive pieces, because developers can this be excused to give up modeling. Many excellent software developers will say they don't want to waste time on these "useless" documents. They indulge in the code and make some fragile and inferior systems. In addition, even many developers who are responsible now think that modeling is an annoying thing, but unwilling to learn the corresponding modeling technology.
Fact Analysis: "Model" and "Document" These two concepts are conceptually. You can have a model that is not a document and a model of the model. A design graph is a model, regardless of drawn on the back of a napkin, or writes on a whiteboard, or in the Class Responsibility Collaboration (CRC) card, or based on the flowchart recorded on the newspaper and cascading paper A rough user interface prototype. Although these can't be said to be a document, they are all valuable models.
Modeling is like a plan: the value of the plan is in the process of planning, rather than planned itself; value is reflected in modeling, not model itself. In fact, the model is not a formal document in your system, and can be lost after completing their mission. You will find that there is only a few models worth retaining, and it must be very perfect.
Misunderstanding 2: From the beginning of the stage you can consider all everything
This kind of saying is popular in the early 1970s to the early 1980s, many managers today have developed software developed at that time. The superstition of this will lead to a considerable time in the previous period to make all everything to get correct, trying to "frozen" all the needs (see misunderstanding) before the start of the coding (see the misunderstanding) "Analyzing period paralysis" - After the model is very perfect, dare to advance. Based on this point, the project team has developed a large number of documents, not what they really want - developed to meet the needs of the needs.
Fact analysis: How can I get out of this misunderstanding? First, you have to realize that you can't take into account all the sub-branches. Second, I realize that the coder may do not act if the work of the model is not as good as (this is possible, the work of the fact that the work "works only in the actual value only), they may say that the model does not respond the truth is. Third, I realize how good your original specification manual is, but the destined code will lose synchronization with it, even if you use your own code. A basic truth is that the code will only be consistent with the code. Fourth, recognize the iterative method (small scale modeling, compiling some code, do some tests, may also make a small work version) is the guidelines for software development. It is a modern heavyweight software development process (such as EUP), as well as the basic principle of lightweight (such as XP). Misunderstanding 3: Modeling means a heavyweight software development process
Project groups walking into this misunderstanding (often associated with the misunderstanding) are often completely abandoned, and it should be too complicated to them for such software development processes. This is no more than a natural disaster.
Fact analysis: You can replace it with a light way. For more details on simply modeling with simple tools, see Agile Modeling (AM). Moreover, you can discard your model When you finish, you can also model it in a very basic manner (for example, starting from the work desk, starting to make a sketch before the whiteboard). As long as you like, you can easily model it.
Misunderstanding 4: Must "freeze" demand
This requirement is often from a senior manager, and they want to know what they can get from this project group. Such a benefit is that the needs of the development cycle will be exactly what is what is what is what is what is the thing is; the disadvantage is that they may not get actually needed (incomplete or wrong demand, translator).
Fact analysis: Change will eventually occur. Due to the changes in priority and gradually understand the system, there will be changes in demand. Contrary to freezing demand, estimating the risk of success, trying to accept changes and take action accordingly, just like XP recommended.
Misunderstanding 5: Design is not changeable
As the misunderstanding four, each developer must strictly comply with "design", causing developers to make a wrong thing in order to meet the "design" or correct things in the wrong way. Or simply ignore the design, denying the benefits of all design possible. Frozen design, you can't get further benefit from learning in the project process. Another big trend is to develop a large number of documents instead of practical software, using a document-oriented CASE tool instead of bringing the project-oriented tool for the project.
Fact analysis: In fact, the design will often modify according to the developer and database administrator, because they are people closest to practical applications, usually their understanding of the technical environment is better than modeling. We must face such a fact: people have not finished, and their work is impossible. Do you really want to fix an imperfect design without modifying the mistake? In addition, if the demand is not frozen, it means that you can't freeze your design, because any demand modification is bound to affect the design. For the correct attitude: As long as your code is still changing, it is not finished.
Misunderstanding 6: Must use the Case tool
Modeling is often considered a complex work, so it is necessary to use the Case tool assistant.
Fact analysis: Yes, modeling can be complicated. But you can fully establish a valid and simple model to express the key information, not some insignificant details.
For example, I often use the UML to build a model to represent classes, their properties and some key business operations, but do not draw access operations (GET and SET), and the frame code for maintaining with other class relations, or other Some trivial achievements. I use the model to find a solution to the problem, let me continue to implement this model with my colleagues. In this flexible way, most cases I don't need a CASE tool to support modeling work, a whiteboard, or a digital camera is enough. In this way, I don't have to take time to evaluate the Case tool, don't have to discuss the license without going to the tool supplier, eliminating the training overhead. The CASE tool is only worth buying when it can reflect the best cost performance (for your own situation). In most cases, I can reach the goal (complete modeling). I often use tools with together / j (http://www.togethersoft.com/) - because it produces a visual Java frame code; there is Erwin (http://www.cai.com/) - Because it can plan the database. These two tools really helped me achieve the purpose of software development - manufacturing software that meets user requirements. But most of my modeling work is still using simple tools, not Case tools. Misunderstanding Seven: Modeling is Waste Time
Many newcomers think so, this is mainly because the education they receive is limited to how to write code, and have a fresh contact for a complete development process. And their experience is only limited to how to implement code, just like a primary programmer. They abandoned opportunities to improve efficiency and learning skills, which allowed them to easily adapt to different projects or organizations. They should be ashamed for this.
Fact analysis: In most cases, draw a sketch before starting the encoding, develop a rod-up prototype or make some index cards to improve your production efficiency. Efficient developers have to model work before encoding. In addition, modeling is a good communication path between project team members and project leaders. You can explore questions in this process, thus getting better understanding, involving each member in the project, can also get a part of a score for the project.
Misunderstanding 8: Data Model (Data Model) is everything
Many organizations are based on the data model to start new development work. Perhaps as your organization: IT department has a very strict provision for data, controlling your development project; or your previous database is a mess, don't choose.
Fact analysis: Data model is an important but not most important modeling, it is best to build on additional models. (See "Extreme Modeling", Thinking Objectively, Nov.2000). This is also the case even in items such as data warehouses. If there is no good understanding of how the user uses this data warehouse (not shown in the data model), these projects often ended with a sad failure. You can use a lot of models - using cases, business rules, Activity Diagrams, Class Diagrams, COMPONENT DIAGRAMS, User Interface Flowchart (User Interface Flow Diagrams) and CRC, etc. . The data model is only one of them. Each model has its strengths and shortcomings, which should be used correctly.
Misunderstanding Nine: All developers know how to model
We are now facing such a serious problem: many people who are not developers, including senior managers and users, do not know how software is built. As a result, they are unable to distinguish the skilled developers and the general programmers (of course, they can't deliver advanced programmers and general programmers). They want to identify all developers to develop the entire system from head to tail. . Fact analysis: This is definitely incorrect. Modeling skills, only when a developer can learn it and have long-term practices. Some very smart programmers often believe that they are all, after all, they are only programmers. Because of such arrogant, some of their tasks is that they don't have the corresponding skills at all. Software development is so complicated, single one is difficult to have all skills to successfully develop, and even impossible to configure a certain complexity system. Developing this should have a self-known understanding, understand their own weaknesses, and learn without end. Through each other, the modeling can learn the specific details of a technology from the programmer, and the programmer can also learn the technique of valuable design and architecture from the model. I personally think everyone, including myself, is a newbie.
Agile model
By understanding and avoiding the modeling misunderstanding, you can have yourself, your project group and your organization have more efficient software development. In the process of revealing these generally existing misunderstandings, many of the principles of Agile Modeling (AM) have been expressed. Agile model is called Extreme Modeling (XM). I hope that I have given you a spiritual food.
Here I would like to thank the Doug Smith, EvaNetics (http://www.evanetics.com) of Blueprint Technology (http://www.evanetics.com, and list in the Agile Modeling Mail (accessible http: / People who contribute this article in /www.agilemodeling.com. I also want to thank Martin Fowler, Ron Jeffries and other members of the XP community, because I think I have already integrated their views.
Modeling ten principles
Only data models are not enough for modern software.
Receive changes and allow your model to improve over time. You can't freeze them, and then look forward to success.
The model is not necessarily a document, and the document is not necessarily a model.
Most models may also be discarded.
Only the code can keep real synchronization with the code.
Some simple tools, such as whiteboards, completely enough to cope with most modeling work.
Reflections, then encode.
You can always learn something from others.
Modeling can be used in a light way.
It is not completed until the code is released.
