How to become a good Software Model Designer

We look forward to becoming a good Software Model Designer. But where should we start?

Apply the following principles to your software engineering, and you will be able to see the results.

1. People are far more important than Technology

You develop software for use by others. software that nobody uses is just a collection of meaningless data. Many of the experts who have made great achievements in software are doing nothing at the early stages of their career, because they concentrated their focus on technology at that time. Obviously, components, EJB (Enterprise Java Beans), and agents are very interesting. However, for users, if the software you design is difficult to use or cannot meet their needs, no matter how good the backend technology is. Spend more time on software requirements and designing an interface that is easy to understand.

2. Understand what you want to implement

Good software designers spend most of their time building system models and occasionally writeSource codeBut it is only to verify the problems encountered during the design process. This will make their design scheme more feasible.

3. modesty is a must.

You can't know everything. You even have to work hard to get enough useful knowledge. Software development is a complex and arduous task, because the tools and technologies used in software development are constantly updated. Moreover, one cannot understand all the processes of software development. In daily life, you may not be exposed to many new things every day. But for software developers, they can learn many new things every day (if they wish ).

4. Demand is demand

If you do not have any requirements, do not develop any software. Successful software depends on the time (completed within the time required by the user), the budget, and whether the user's needs are met. If you cannot know exactly what the user needs or define the software requirements, your project is doomed to fail.

5. The demand actually rarely changes. What changes is your understanding of the demand.

Doug Smith of object toolsmiths (www.objecttoolsmiths.com) often said: "analysis is a science and design is an art ". He means that there is only one "correct" analysis model among the many "correct" analysis models that can fully meet the needs of solving a specific problem (I understand that it means requirement analysis. meticulous and accurate completion, in design, creativity and imagination can be used instead ).

If the demand changes frequently, it is likely that you have not analyzed the demand, but it is not that the demand has actually changed.

You can complain that users cannot tell you what they want, but don't forget that it is your job to collect requirement information.

You can say that new developers make a mess, but you should be sure to tell them what to do and how to do it on the first day of the project.

If you feel that the company does not allow you to fully engage with users, it only means that the company's management does not really support your project.

You can complain that the company's software engineering management system is unreasonable, but you must understand how most of the companies in the same industry do it.

You can use an excuse to say that your competitors are successful because they have a new idea, but why didn't you think about it first?

There are few real changes to requirements, but there are many reasons for not doing a good job in requirement analysis.

6. Read frequently

In this industry that is changing every day, you cannot indulge in the achievements that have been made for too long.

Read at least two or three professional magazines or one professional book each month. It takes a lot of time and money to keep yourself out of date, but it will make you a strong competitor.

7. Reduce coupling between software modules

Systems with high coupling degree are difficult to maintain. One modification causes another or more changes.

You can downgrade by using the following methods:ProgramCoupling Degree: Hiding implementation details, forcing component interface definitions, without using public data structures, and preventing applications from directly operating the database (my rule of thumb is: when application programmers write SQLCodeThe Coupling Degree of your program is very high ).

Software with low coupling can be easily reused, maintained, and expanded.

8. improve software cohesion

If a software module only implements one function, the module has a high cohesion. High Cohesion software is easier to maintain and improve.

Determine whether a module has a high cohesion and whether you can use a simple sentence to describe its function. If you use a paragraph or you need to use a hyphen like "and", "or", it means you need to refine this module.

Only highly cohesive modules can be reused.

9. Considering software portability

Porting is a specific and practical task in software development. Do not trust the advertisement promotion of some software tools (such as the Java promotion slogan write once run every? Translator's note ).

Even if you only perform regular software upgrades, it is as important as porting to another operating system or database.

Do you remember the "fun" of porting 16-bit windows to 32-bit windows? When you use the features of an operating system, such as its inter-process communication (IPC) policy, or write a stored procedure in a database proprietary language. Your software has a high degree of integration with that particular product.

Good software designers hide the specific implementation details. So when those features need to be changed, you only need to update the package.

10. accept changes

This is an old saying: The only thing that remains unchanged is change.

You should record all possible changes and potential requirements of the system so that they can be implemented in the future (see "logging for Change", thinking objectively, May 1999)

By considering these assumptions During modeling, you may develop strong and easy-to-maintain software. Designing strong software is your basic goal.

11. Do not underestimate the demand for software scale

The biggest lesson that Internet brings us is that you must consider the scalability of software at the initial stage of software development.

Today, applications used by departments with only 100 people may be used by tens of thousands of organizations tomorrow and may be used by millions of people over the Internet next month.

At the early stage of software design, the basic functions of the software are determined based on the basic transactions that must be supported as defined in the case model. Then, we gradually add frequently-used functions when building the system.

Consider the scale of software at the beginning of the design to avoid software rewriting when the user base suddenly increases.

12. performance is just one of many design factors

Focusing on performance, an important factor in software design, seems to be the most important concern of users. A software with poor performance will inevitably be overwritten.

However, your design must also be reliable, available, portable, and scalable. You should define and differentiate these factors at the beginning of the project so that they can be used properly at work. The performance can be or is not the highest priority. In my opinion, each design factor should be considered.

13. Management Interface

In the "UML User Guide" (Grady booch, Ivar Jacobson and Jim Rumbaugh, Addison Wesley, 1999), you should define interfaces between software modules in the early stages of development.

This helps your developers fully understand the software design structure and reach consensus, so that the development teams of each module can work relatively independently. Once the Module Interface is determined, how to implement the module is not very important.

Fundamentally, if you cannot define what your module looks like from the outside, you certainly do not know what to implement in the module.

14. Approaching the road takes a longer time

There are no shortcuts in software development.

Shorten the time you spend on Requirement analysis. The result is that the developed software cannot meet your needs and must be overwritten.

Every week of software modeling is saved, and it may take several more weeks in the future coding phase, because you can write programs before you fully think about them.

You missed a bug to save a day's test time. In the future maintenance phase, it may take weeks or even months to fix it. In this case, it is better to reschedule the project.

Do it once by doing it right ).

15. Don't trust anyone

Product and Service sales companies are not your friends, and most of your employees and senior management staff are not.

Most product vendors want to tie you firmly to their products, which may be operating systems, databases, or a development tool.

Most consultants and contractors only care about your money and not your project (stop paying them and see how long they will stay around ).

Most Programmers think that they are better than others, and they may abandon the model you designed and use what they think is better.

Only good communication can solve these problems.

It should be clear that you should not rely solely on a product or service provider, even if your company (or organization) has invested a lot of money in modeling, documentation, and process.

16. Prove that your design is feasible in practice

A technical prototype, or an "end-to-end" prototype, should be created before design. To prove that your design can work.

You should do this in the early stages of development, because if the software design scheme is not feasible, No matter what measures are taken in the coding implementation phase. The technical prototype will prove the feasibility of your design, so that your design will be more easily supported.

17. Known application modes

Currently, we have a large number of off-the-shelf Analysis and Design Patterns and solutions to problems.

In general, good model design and developers will avoid re-designing mature and widely used things.
The http://www.ambysoft.com/processPatternsPage.html has a collection of many development patterns of information.

18. Study the strengths and weaknesses of each model

There are currently many types of models available, as shown in. The Use Case captures system behavior requirements, and the data model describes the data structures required for a system operation. You may try to add the actual data description to the use case, but this is not very useful to developers. Similarly, data models are useless for describing software requirements. Each model has a corresponding position in your modeling process, but you need to understand where and when to use them.

19. apply multiple models to existing tasks

When collecting requirements, consider using case models, user interface models, and domain-level class models.

When designing software, you should consider making class models, sequence diagrams, state diagrams, collaboration diagrams, and final software physical models.

Programmers should gradually realize that software implemented by using only one model cannot meet user needs well or be difficult to expand.

20. Educate Your Audience

You have made a lot of effort to build a very mature system model, but your audience cannot understand them, or even worse-they don't even know why to build a model first. So your work is meaningless.

It teaches you the basic modeling knowledge of developers. Otherwise, they will only look at the beautiful charts you have drawn and continue to write nonstandard programs.

In addition, you also need to tell your users some basic knowledge about requirement modeling. Explain your use cases and user interface models to help them understand what you want to express. When everyone can use a Universal Design Language (such as the UML-Translator note), your team can truly cooperate.

21. dummies with tools

You gave me a CAD/CAM tool and asked me to design a bridge. However, if the bridge is built, I certainly don't want to be the first person to cross the bridge, because I don't know anything about the building.

Using a very good case tool does not make you a modeling expert, but can only make you a user of a good case tool. It takes years to become an excellent modeling expert. It is not a week's training on a tool worth thousands of US dollars. 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. Understand the complete process

Good Designers should understand the entire software process, although they may not be proficient in all implementation details.

Software development is a complicated process. Do you still remember the content on page 36th of object-oriented software process? In addition to programming, modeling, and testing, you have to do a lot of work.

Good Designers need to consider the global. In the long run, we must consider how to make the software meet user needs and how to provide maintenance and technical support.

23. often perform tests and early tests

If testing doesn't matter to your software, most of your software will not need to be developed.

Create a technical prototype for technical review to test your software model.

In the software life cycle, the later the error is detected, the more difficult it is to modify, the more expensive the modification cost. It is worthwhile to do the test as early as possible.

24. Archiving your work

The work that is not worth archiving is often not worth doing. Archive your ideas and decisions made based on ideas; important but not obvious parts of the archive software model. Give each model a brief description so that others can quickly understand what the model expresses.

25. The technology will change and the basic principle will not

If someone says "using a development language, a tool, or a certain technology, we don't need to perform requirement analysis, modeling, coding or testing ". Don't believe it. This only shows that he still lacks experience. Aside from the technical and human factors, the basic principles of software development have not changed since 1970s. You must also define requirements, modeling, coding, testing, configuration, risks, Release Products, and management staff.

Software Modeling Technology requires years of practical work to be fully mastered. Fortunately, you can improve your software development experience from my suggestions.

Start with chicken soup and add your own vegetables. Then, start enjoying your own big dinner.