How to become an excellent software model designer?
Author: Scott Ambler with, music Raymond translated article taken from: www.umlchina.com we expect to become a model of good software designers, however, what to do, and from where to start? Apply the following principles to your software engineering, you will get the results of the standby rod. 1. People are more important to develop your development software for others, and no one is used by the software that has no meaningful data. Many hipsters in software are flat in the early days of their career, because they will focus on the main energy at that time. Obviously, components, EJB (Enterprise Java Beans, and Agent) are very interesting. But for the user, if your software is difficult to use or you can't meet their needs, the background uses better technology to do things. Multi-speaking time to software needs and design a user can easily understand the interface. 2. Understand the good software designer you want to achieve, spend most of the time on building a system model, occasionally writing some source code, but it is just to verify the problems encountered during the design process. This will make their design more feasible. 3. Modest is a must-have you can't know everything, you don't even work hard to get enough knowledge. Software development is a complex and arduous job because software development has been continually updated. Moreover, a person is impossible to understand all the processes developed. The fresh things that you have contacted daily in everyday life may not be too much. But for people engaged in software development, you can learn a lot of new things (if you want) every day. 4. The demand is that if you don't have any needs, you don't want to develop any software. Successful software depends on time (completed within the time required), the budget and whether the user needs to meet the needs of users. If you can't exactly know what the user needs, or the demand definition of the software, then your project is destined to fail. 5. The demand is actually rarely changed, and the Doug Smith, which is what you understand the needs of Object Toolsmiths, often like: "Analysis is a science, design is an art." He means that there is only one "correct" analysis model in many "correct" analysis models that can fully meet the needs of a specific problem (I understand what needs analysis requires meticulous, accurate completion, and design Instead, you can play creativity and imagination - translator's note). If the demand is often changed, it is likely that you don't have a need for demand analysis. It is not really changed. You can complain that users can't tell you what they want, but don't forget, collecting demand information is your work. You can say that the new developers make things a mess, but you should determine what should I do and how to do it in the first day of the project. If you think that the company does not allow you to get into contact with users, you can only explain the company's management is not really supporting your project. You can complain that the company's management system is unreasonable, but you have to know how Most of the same contact is doing. You can excuse your competitors' success because they have a new idea, but why didn't you think of it first? There are very few things that demand truly change, but there is no reason to do a good job of demand analysis. 6. Reading frequently at this daily industry, you can't be intoxicated too long in your achievements. Reads at least 2,3 professional magazines or 1 professional books per month. Keeping a lot of time and money, but will make you a very powerful competitor. 7. The system that reduces the coupling degree of the software module is difficult to maintain. The modification of one is caused to change the changes in even more.
You can reduce the coupling of the program by the following methods: Hide implementation details, force the component interface definition, do not use the public data structure, do not allow the application to directly operate the database (my experience is: When the application is written when writing SQL code The coupling of your program is already very high). Software with low coupling can be easily reused, maintained, and expanded. 8. Improve the cohesiveness of the software If a software module implements only one function, then the module has high cohesiveness. High cohesive software is more easily maintained and improved. Determine if a module has high cohesiveness, see if you can describe its function with a simple sentence. If you use a bit or you need to use similar words "and", "or", you need to refine the module. Only high cohesive modules may be reused. 9. Consider the software development is a specific and actual job in software development, do not believe that some software tools advertisement (such as Java's propaganda slogan Write Once Run Many Translator Note). Even if only the software is regularly upgraded, it is also as important as it is as important as the other operating system or database transplant. Remember to transplant from 16 Windows to 32-bit Windows "fun"? When you use a feature of an operating system, such as its process communication (IPC) policy, or writing a stored procedure with a database. Your software and that specific product combination are already very high. A good software designer packed the unique implementation details, so when those features change, you just need to update that package. 10. This is an older story: the only change is only changed. You should record all systems will have possible changes and potential demand for future implementation (see "Architecting for Change", Thinking Objectively, May 1999) You will develop by considering these assumptions during modeling. Software that is strong enough and easy to maintain. Designing strong software is your most basic goal. 11. Don't underestimate the size of the software size Internet brings us the biggest lesson to us is that you must consider the scalability of software scale in the initial stage of software development. Today, only 100 applications used by the department, which may be used by tens of thousands of people tomorrow, next month, there may be millions of people through the Internet. In the early stages of software design, the basic functions of the software are determined according to basic transactions that must be supported in the use case model. Then, gradually add a relatively common function when the system is constructed. In the design, consider the size demand of the software, avoid rewriting the software if the user group is suddenly increased. 12. Performance is only one of many design factors to pay attention to an important factor in software design - performance, this seems to be the user's most concerned. A poor performance will inevitably be rewritten. But your design must also have reliability, availability, portability, and scalability. You should define and distinguish these factors in the start of the project to use it in your work. Performance can be, or it is not a priority factor, my point of view is to give each design factor consideration. 13. Management interface "UML User Guide" (Grady Booch, Ivar Jacobson, 1999) pointed out that you should define the interface between software modules in the early days of the development phase. This helps your developers fully understand the software design structure and make unanimous comments, so that the module development team is relatively independent. Once the interface is determined, the module is not very important. Fundamentally, if you can't define your module "What will look like outside", you are sure you don't know what you want to implement within the module.
14. Take a long time to take a longer time in software development, there is no shortcut to go. Shorten your time spent on demand analysis, the result can only be developed software that cannot meet the needs of users, must be rewritten. Every week in the software modeling, it will spend more time for a few weeks during the future coding phase, because you will write a handwritten program before comprehensively thinking. In order to save a day's test time, you will miss a bug, in the future maintenance stage, it may take a few weeks or even a few months to repair. In this way, it is better to rearrange the project plan. Avoid picking up the cantress, only one time but do it (Do It oncé by doing it right). 15. Don't trust anyone's products and service sales companies are not your friend, most of your employees and senior management are not. Most product suppliers want to tie you in their products, which may be operating systems, databases, or a development tool. Most consultants and contractors are only concerned about your money is not your project (stop paying them to you, see how long they will stay around). Most of the programmers think they are more excellent than others, they may abandon your design model and think it is better to use it. Only good communication can solve these problems. It is clear that do not rely on a product or service provider, even if your company (or organization) has invested a lot of money to the company in terms of modeling, documentation and procedures. 16. Prove that your design can first establish a technique prototype when it is designed in practice, or is called "end-to-end" prototype. To prove your design is capable. You should do these things in the early days of development, because if the software design is not feasible, there is no matter what measures taken in the code implementation phase. The technical prototype will prove the feasibility of your design, so your design will be easier to support support. 17. Apply known modes Currently, we have a large number of ready-made analysis and design patterns and solutions to solutions. Generally speaking, good model design and developers will avoid redesigning mature and widely used things. http://www.ambysoft.com/processpatternspage.html The information of many development modes is available. 18. Study the strengths and weaknesses of each model currently have many models of models, as shown below. The use case captures is system behavior requirements, and the data model describes the data required to support a system run. You may try to join the actual data description in the use case, however, this is not very useful to developers. Similarly, the data model is useless to describe software requirements. Each model has its corresponding position during your modeling, however, you need to understand where, when you use them. 19. Applying multiple models in existing tasks When you collect demand, consider using the use case model, user interface model, and class-level models. When you design the software, you should consider making a class model, sequential diagram, state diagram, collaboration map, and final software actual physical model. Program designers should slowly realize that software implemented only with a model is either unable to meet the needs of users, or it is difficult to expand. 20. Education Your listener, you spend a lot of strength to build a very mature system model, but your audience can't understand them, even worse - even why do you want to build a model. Then your work is meaningless. Teach your developer's basic modeling knowledge; otherwise, they will only look at the beautiful graphs you draw and continue to write irregular procedures. In addition, you also need to tell you some basic knowledge of some need modeling. Explain your use case and user interface model so they understand what you want to express. When everyone can use a universal design language (such as UML-Translator Note), your team can realize real cooperation.
