How to become good designers software model?

Posted on 2009-06-24 filed under: Development (RSS) 40 views

Author: Scott Ambler, and translation of Le Lin Feng
This article from: www.umlchina.com
March 25, 2002

We look forward to become an excellent model of software designers, but what to do, and from where to start?

The following principles will be applied to your software project, you will receive immediate results.

1. People important than technology

You to develop software for others to use, no software to use does not make sense is the collection of data only. Many of the achievements of software experts are in their early stage of the cause of the performance is mediocre, because they then will be the main energy Hou has focused on the technical. Clearly, the component (components), EJB (Enterprise Java Beans) and agents (agent) is very interesting. But for users, if you design the software difficult to use or can not meet their needs, no matter how good the background of the technology used does not help. Spend more time needs and the software allows users to design an easy to understand interface.

2. To understand the things you want to achieve

Good software designers to most of the time spent on the establishment of the system model, and occasionally write some source code, but only the design process in order to verify that the problems encountered. This will enable them to design more feasible.

3. Modesty is necessary character

You can not know everything, you even have to work very hard to get sufficient knowledge. Software development is a complex and difficult task, as used by software development tools and techniques are constantly updated. Moreover, a person can not understand all the process of software development. In daily life you come into contact with the fresh every day may not be too many things. But for those who engage in software development, the daily lot of new things to learn (if they so wish).

4. The demand is the demand for

If you do not have any needs, you should not do any software development. Time depends on the success of the software (user requirements in time), budget and whether or not to meet the needs of users. If you do not know exactly what users need or demand for the definition of software, then your project is doomed to fail.

5. In fact, very little needs to change, change is the understanding of your needs

Object ToolSmiths Company (www.objecttoolsmiths.com) often likes of Doug Smith said: "The analysis is a science, design is an art." What he means is that a large number of "correct" model there is only one of the most "correct" analysis of the model solution can fully meet the needs of a particular problem (I understand the meaning of needs analysis is the need for meticulous and accurate completion of the design it can be a time when creativity and imagination - translators note).

If the demand changes frequently, it may be you do not prepare needs analysis, the demand is not really changed.

You can complain that the user can not tell you what they want, but do not forget to collect the demand for information is your work.

You can say that the development of new staff to bring the issue to a mess, but, you should determine on the first day of work to tell them what they should do and how to do that.

If you feel that the company will not let you have full access to the user, it only shows the company's management is not really support your project.

You can complain about the software project management system is unreasonable, but you must understand the most is how peers do.

You can excuse that the success of your competitors because they have a new idea, but why do you not think of it first?

Needs very little real change in the situation, but did not do a good job in the demand for analytical work has a lot of reasons.

6. Read

Every day in this industry is changing, you can not have achievements too intoxicated.

2,3 this month at least reading a professional journal or professional books. Do not need to do to keep out a lot of time and money, but will make you become a very strong competitors.

7. To reduce the coupling between software modules degrees

High-coupling system is very difficult to maintain. Changes caused by one another or even more changes in Office.

You can process the adoption of the following ways to reduce the coupling degree: hide implementation details, the mandatory component interface definition, do not use the common data structure, not the direct operation of the application database (my rule of thumb is: When the application programmer to write SQL code in the time , your program has a high degree of coupling a).

Low coupling software can easily be reused, maintenance and expansion.

8. Improve software cohesion

If a software module is only the realization of a function, then the module with high cohesion. High cohesion of the software easier to maintain and improve.

To determine whether there is a module with high cohesion, and look at you in a position to use a simple sentence to describe its features on the list. If you use a period or if you need to use similar "and", "or" conjunctions, etc., then you need to refine the module.

Only the high cohesion of the modules can be reused.

9. To consider the portability of software

Software development in transplantation is a concrete and practical work, do not believe that the advertising of certain software tools (such as java slogan write once run many? Translators note).

Even if only conventional software upgrade, but also to see and this operating system or database to another is as important as transplantation.

I remember from the 16-bit Windows transplanted into 32 windows of the "pleasure" in it? When you use a certain operating system features such as its inter-process communication (IPC) strategy, or a proprietary database of the stored procedure language. Your software and products that particular combination of degrees on the already high.

Good software designers to achieve those specific details hidden package, so that when those characteristics of the change, you only need to update that package on it.

10. To embrace change

This is an old saying: the only constant, only change.

You should be all systems will be possible changes in demand and the potential recorded in order to achieve the future (see "Architecting for Change", Thinking Objectively, May 1999)

During the consideration by modeling the situation of these assumptions, you may be strong enough to develop and easier to maintain software. Strong software design and your basic goals.

11. Do not underestimate the scale of demand for software

Internet brought us the biggest lesson is that you must be in the initial stages of software development on the scale of software scalability.

Today, only 100 people and that the use of applications, tomorrow may be several tens of thousands of people's organizations, next month, via the Internet, there may be millions of people use it.

In the early stages of software design, in accordance with the definition of use case model must support the basic transaction processing to determine the basic functions of software. Then, when the construction of the system gradually by adding commonly used functions.

Considered in the design of the beginning of the scale of demand for software to avoid a sudden increase in user base, the re-writing software.

12. Performance is just one of many design factors

Concerned about the software design is an important factor - the performance, it is as if the user most concerned about. A poor performance will inevitably be re-writing software.

But you also must have the design of reliability, availability, portability and scalability. You should be in the works to define and distinguish between these factors, so that appropriate use of work. Performance can be, it may not be the highest priority of the factors, my view is that the design factors for each due consideration.

13. Management Interface

"UML User Guide" (Grady Booch, Ivar Jacobson and Jim Rumbaugh, Addison Wesley, 1999) pointed out, you should phase in the development of early definition of the interface between software modules.

This will help your software developers to design a comprehensive understanding of the structure and agreed to allow the module development teams working relatively independent. Once the module's interface is established, how to achieve the module is not very important.

Fundamentally speaking, if you can not define your module "looks like from the outside", you certainly do not know what modules to achieve.

14. Approached the way the need for a longer period of time

In software development can not take shortcuts.

On the demand to shorten your time spent on analysis, the result can only be developed by the software can not meet the needs of users, must be rewritten.

Modeling software to save every week, phase encoding in the future may be to spend a few weeks time, because you are thinking in a comprehensive written procedures before they do.

In order to save you time and test day missing a bug, in the future maintenance phase, may take weeks or even months to repair. With the case, you might as well project rescheduling.

Avoid short-cut, only to be done on time but (do it once by doing it right).

15. Do not trust anyone

Sales of products and services is not your friend, your most senior management staff and not yes.

Supply most of the products you want to firmly tied to their products, may be the operating system, database, or a development tool.

Most of the consultants and contractors only care about your money not your project (to stop payments to them, they will take a look at how long to stay in the surrounding).

Most programmers think that they own better than others, they may abandon the model of your design that better use their own.

Only good communication in order to solve these problems.

Should be clear that not only rely on a product or service provider, even if your company (or organization) has been in the modeling, documentation and processes to the company invested a lot of money.

16. That you design feasible in practice

Time in the design should be to create a technical prototype, or referred to as the "end-to-end" prototype. To prove that your design is able to work.

You should work in developing early to do all these things, because, if the software design is not feasible to achieve in the encoding phase of whatever measures are useless. Technology prototype will prove the feasibility of your design, so that your design will be easier to support.

17. Application of the model known

At present, we have a large number of off-the-shelf analysis and design models and solutions can be used.

In general, a good model for the design and development of staff, will avoid the re-design has been widely used and mature things. http://www.ambysoft.com/processPatternsPage.html collection of information on many development model.

18. Look into each model's strengths and weaknesses

There are many types of models can be used, as shown in Fig. Use case is to capture the demand for system behavior, data model to describe the support needed to run a system constitute the data. You might try adding use case description of the actual data, but it is not very useful to developers. Similarly, the data model needs to describe the software is useless. Each model in your modeling process has its corresponding position, but you need to understand where, when to use them.

19. In a number of existing mandates the application of model

When you gather requirements, when considering the use of use case model, user interface model and the field-level class model.

When you design software must be looked at in the production class model, sequence diagram, state diagrams, collaboration diagrams, and ultimately the actual physical model of the software.

Programmers should be gradually realized that only the use of a model to achieve either of the software can not be well positioned to meet the needs of users, or it is very difficult to expand.

20. Educate your audience

You spent a great effort to build a system model is very mature, and you did not understand their audience, or even worse - even before the establishment of model why do not know. Then your work is meaningless.

Teach you to develop the basic knowledge of modeling; Otherwise, they will only look at the chart you beautiful painting, and then continue to the preparation of non-standard procedures.

In addition, you also need to tell your users the basics of demand modeling. To explain your use case (uses case) and user interface model, to enable them to understand and express what you want. When everyone can use a common language of the time (such as UML-Translator's Note), your team can realize true cooperation.

21. Fool with a tool or fool

You for giving me the CAD / CAM tools, asked me to design a bridge. However, if the bridge built, I certainly did not want to be the first person off from the bridge, because I know nothing about construction.

A very good use of CASE tools do not allow you to be a modeling expert, you will only be a good CASE tool users. Be a need for good modeling experts have accumulated over the years will not be a week worth thousands of dollars for a training tool. A good CASE tool is very important, but you must learn to use it, and be able to use it to design the model it supports.

22. To understand the complete process

Good designers should understand the entire software process, although they may not be well versed in all the details.

Software development is a very complicated process, but also remember that "object-oriented software process" on page 36 of the content? In addition to programming, modeling, testing and other work you are good at, there are a lot of work to do.

Designers need to consider the overall good. Must be considered from a long-term how to make the software to meet user needs, how to provide maintenance and technical support.

23. Regular testing, early testing

If the test of your software is no, then most of your software is no need to be developed.

Technology for the establishment of a technical assessment of the use of a prototype to test your software model.

In the software life cycle, the more errors later found in the more difficult to amend, modify the cost of the more expensive. Test as soon as possible is very worthwhile.

24. To archive your work

Not worth the work of archiving is often not worth doing. Your idea of archiving, as well as the decision is envisaged; archiving software model but a very important part is not very clear. Summary of each model to describe a number of others in order to quickly understand the content of the expression of the model.

25. Technological change, the basic principles will not

If someone says that "the development of the use of a language, a tool or a certain technology, we do not need to do needs analysis, modeling, coding or testing." Do not believe that this shows that he is also a lack of experience. Set aside the technical and human factors, in fact, the basic principles of software development since the 20th century, since the 70's never changed. You must also define requirements, modeling, coding, testing, configuration, in the face of risk, release products, the management of staff and so on.

Software modeling technology is the actual work will take many years to completely master. Fortunately, you can from the beginning of my proposal, and improve your own experience in software development.

To chicken soup to start, by adding their own vegetables. Then, you begin to enjoy your dinner.