How to become a good Software Model Designer

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 software vendors
Well-accomplished experts did nothing at the early stages of their career, because they concentrated their focus on technology at that time. Apparently,
Components, EJB (Enterprise Java Beans), and agents are interesting. However
If the software you designed is difficult to use or cannot meet their needs, no matter how good the backend technology is. More
Time to software requirements and design an interface that makes it easy for users to understand.
2. Understand what you want to implement
Good software designers spend most of their time building system models and occasionally write some source code.
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 those who are engaged in software development, they can learn every day.
Many new things (if you want ).
4. Demand is demand
If you do not have any requirements, do not develop any software. Successful software depends on the time (within the time required by the user
Completed), budget, and whether to meet user needs. 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 says: "analysis is a subject.
Design is an art ". He means that there is only one of the most "correct" analysis models.
To fully meet the needs of solving a specific problem (I understand that the demand analysis needs to be meticulous and accurate, and the design
Instead, you can use your creativity and imagination ).
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 on the first day of the project
What to do and how to do it.
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 stay out of date,
Make you a strong competitor.
7. It is difficult to maintain systems that reduce the Coupling Degree between software modules and have a high Coupling Degree. One modification causes another or more changes.
You can reduce the Coupling Degree of a program by hiding implementation details, forcing Component Interface Definition, and not using public data structures,
Do not allow the application to directly operate the database (my rule of thumb is: when the application programmer is writing SQL code, the coupling of your program
).
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 modify
.
Determine whether a module has a high cohesion and whether you can use a simple sentence to describe its function. If
If you use a paragraph or you need to use a hyphen like "and", "or", You need to refine the module.
Only highly cohesive modules can be reused.
9. Considering software portability
Transplantation is a specific and practical task in software development. Do not trust the advertisement of some software tools (such as Java Publicity
Write Once run failed? 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
Its inter-process communication (IPC) policy, or the stored procedure is written in a database proprietary language. The degree of integration between your software and that particular product
It is very high.
Good software designers package and hide the specific implementation details, so when those features need to be changed, you just need
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 for future implementation (see
"Processing ting for Change", thinking objectively, May 1999)
By considering these assumptions During modeling, you may develop strong and easy-to-maintain software. Strong Design
Software is your most 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.
Applications used by departments with only 100 people today may be used by tens of thousands of organizations tomorrow.
It may be used by millions of people.
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. However
And then gradually add more common 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 not
To avoid rewriting.
However, your design must also be reliable, available, portable, and scalable. You should define the partition at the beginning of the project.
Divide these factors 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
"UML User Guide" (Grady booch, Ivar jacbson and Jim Rumbaugh, Addison Wesley, 1999)
It is pointed out that 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 independently.
. Once the Module Interface is determined, how to implement the module is not very important.
Basically, if you cannot define what your module looks like from the outside, you certainly do not know what the module looks like.
What to implement.
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 should do it before you fully Think About It.
Write a program.
You have missed a bug to save a day's test time. It may take weeks or even months for future maintenance.
Time to repair. 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 if they will stay around much
Long time ).
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 one product or service provider, even if your company (or organization) is already modeling, documenting, and passing through
Cheng invested a lot of money in that company.
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 is able to work
.
You should do this in the early stages of development, because if the software design scheme is not feasible, there is no
No action can be taken. 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 supports description.
The data structure required for running a system. You may try to add the actual data description to the use case.
It is often used. Similarly, data models are useless for describing software requirements. Each model has its own location in the modeling process,
Yes, 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 users' needs well.
It is either 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-why?
I do not know how to create a model first. So your work is meaningless.
Teach you the basic modeling knowledge of developers; otherwise, they will only look at the beautiful charts you have drawn, and then continue to write nonstandard Processes
.
In addition, you also need to tell your users some basic knowledge about requirement modeling. Explain your use cases and users to them
Interface model, so that they can understand what you want to express. When everyone can use a Universal Design Language (such
UML-Translator's note), your team can achieve real cooperation.
21. dummies with tools
You gave me a CAD/CAM tool and asked me to design a bridge. However, if that bridge is built, I certainly don't want to be the first bridge.
Because I have no idea about architecture.
Using a good case tool does not make you a modeling expert, but can only make you an excellent case tool.
User. It takes years to become an excellent modeling expert. It is not a week's training on a tool worth thousands of US dollars. One
A good case tool is 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 your ideas.
Important but not obvious. 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 test ". Don't believe it. This only shows that he still lacks experience. Aside from the technical and human factors, the basic principle of software development is actually self-built.
It has not changed since 1970s. You must also define requirements, modeling, coding, testing, configuration, risk-oriented, production release
Product, management staff, etc.
Software Modeling Technology requires years of practical work to be fully mastered. Fortunately, you can improve yourself from my suggestions.
Software development experience.
Start with chicken soup and add your own vegetables. Then, start enjoying your own big dinner.