Linuxaid.com.cn 01-07-16 11:51 937p
Axing
From programmers to system analysts, everyone should be familiar with these two words, but the meaning of the words may not be particularly clear. First, it must be said that programmers and system analysts do not exist who are senior and low-level respective respects, they are two professions, and they are completely different for vocational skills. So powerful programmers are wrong to system analysts. Of course, the system analyst's skill requires that he must know how to write the program, but his focus is how to cut a large item into a small piece suitable for personal, then organize these small pieces. The programmer's duty is how to better implement these small pieces faster. Before this chapter, we discuss the skills of qualified programmers should have, and of course there are more than that. The reason why it is inserted here to discuss system analysts because our column is called software engineering instead of programmers from entry to proficiency. Before the official start, we still look at the author of Thinking in Java's alive opinion on the analysis and design: analysis and design of object-oriented paradigm is a new, and many people are most different. Start how to construct a project on how to construct a project. In fact, we can make a "good" design that makes full use of all the advantages provided by OOP. Please forgive this word that suddenly appeared here. He means that the face is the object, although there is no mention before, but in the current OO concept, you should not be too strange to him. Here I briefly explain it. Before I introduced, I actually had experienced experience (what, teaching us old antiques, playing him!), But the previous non-OO (process) software design method is currently internationally I rarely adopted, so all the concepts of all the concepts are OO. Even if the concept of io is very simple, everyone thinks, we will use it when you learn C , the categories used in the beginning are not all animals, the squares, the like, the examples, right. In fact, OO is a way we look at the world. However, due to the non-developed computer technology, we have to use some strange description to express our meaning, only such a computer can understand, is very stupid? For example, we must use parameters, procedures, and functions. So the software design method at that time is based on the process. A simple example to show the difference between the OO design method and the process-based design method: a simple daily phrase - "I eat", use OO method to express or "I eat", but if I use the process If the method is described, it will become "I eat (meal)", is it very awkward? If you feel that there is any problem with the OO method, you can go to another special article under the software engineering column: "Thinking in Java Appreciation" about OOP analysis and design books are not satisfactory. Most of these books are filled with inexplicable words, clumsy writes, and many of them seem to be very important. I think this book is preferably compressed to a chapter, and I write to a very thin book. Ironing is that those who specially focus on complex things management often write some shallow and understand the book! If you can't be said simple and direct, there is not much man who likes to watch this. After all, all the purposes of OOP is to make the process of software development easier. Although this may affect the livelihoods that like to solve complex problems, why not make things simple from the beginning? Therefore, I hope that I can start a good foundation for everyone, and use a few paragraphs to clearly analyze and design problems. Don't be lost throughout the development process, the most important thing is: don't lose your own! But in fact, this kind of thing is easy. Most methods are designed to solve the problem of the maximum range.
Of course, there are some special difficulties, and the authors need to pay more hard efforts or pay more. However, most projects are comparable "General", so they can generally make successful analysis and design, and only a small number of methods recommended. But no matter how limited, some forms of processing are always beneficial, which makes it easier for the development of the entire project, and it is better than the beginning of the code! That is, if you are looking at a special method, there is a lot of details, and many steps and documents are recommended, so it is still difficult to correctly determine when you stop. Always remind yourself to pay attention to the following questions: (1) What is the object? (How to divide your project into a series of separate components?) (2) What is their interface? (What news is needed to send to every object?) After determining the object and their interface, you can do a program. For the consideration of many reasons, it may also need more instructions and documents than this, but the information required to master is absolutely not less than this. The entire process can be divided into four phases, and the stage 0 has just begun to use certain forms of structures. Phase 0: The first step in which a plan is to determine which steps take in the later process. This seems to be very simple (in fact, everything we say here seems to be very simple), but a common situation is: Some people have not even entered the stage 1, so they are busy start writing code. If your plan is "directly starting coding", it is certainly unambiguous (if there is a thorough understanding of the problems you have to solve, you can think about it). But the lowest level should also agree to have a plan. At this stage, it may be necessary to decide some necessary additional processing structures. But very unfortunately, some programmers like to write the program, they like to think, they think "naturally will be completed when they are completed." In this way, don't have any problems, but I feel that if you can set a few flags throughout the process, or "road sign" will be more beneficial to you. This is probably much better than simply for "completing work". At least, after another goal, after passing one of the road signs, you can have a clear grasp of your progress, and the strength will also increase accordingly, and it will not generate the feeling of "roadmaking." From my beginning of studying story (I want to write this novel), I have been insisting on this practice, I feel like it is simply "stream" to paper. When I wrote something related to the computer, I found that the structure is much more simpler than the novel, so there is no need to consider too many questions. But I still have developed the structure of the whole writing, so that I have to write something to write. Therefore, even if your plan is to start writing procedures, you still need to experience the following phases, and put forward some specific issues to yourself. Stage 1: What should you do? In the previous generation program design (ie "process or programming design"), this stage is called "establishing a demand analysis and system specifications". Of course, those operations are no longer needed today, or at least the form is changed. A large number of headache documentation has become history. But the original intention is good. The meaning of demand analysis is to "establish a range of rules. If it is determined by it, when it is done, and how the customer can satisfy." System specification means "Here is some specific instructions, let you know what the program needs to do (not what) can meet the requirements." Demand analysis is actually a contract between you and customers (even if the customer works within the company, or other objects and systems).
The system specification is an disclosure of the highest level of the problem, which we determine if the task is completed and takes more time. Since these are all the unanimous consent of the participant, I recommend simplifying them as much as possible - it is best to use the list and basic charts in the form of saving time. It may also face other restrictions, you need to expand them into larger documents. We must pay special attention to the core issue of this phase, do not entangle the end of the sub-branches. This core problem is: what system is decided. For this problem, the most valuable tool is a collection called "Use Condition". This is the most convincing answer for those in the form of "how to do it?", " For example, "If the customer needs to extract a cash check, but there is no so many cash reserves, then how do you respond to the ATM?" For this issue, "Use Condition" can indicate that the ATM is in that kind of "condition" Correct operation below. It should be summarized as a complete set of "use conditions" or "application". Once this is completed, it is equivalent to finding the core task that wants to complete the system. Since it is focused on "use conditions", a good effect is that they can always put them in the most critical thing, and prevent themselves from distinguishing them on other things that are not big to complete the task. That is, as long as you have a complete set of "use conditions", you can make a clear description of your own system and transfer to the next phase. At this stage, it is also possible to fully grasp the various applications of the system in the future, but this has no relationship. As long as it is willing to spend time, all problems will naturally be exposed. Don't pay more about the "perfect" specifications of the system, otherwise it is easy to produce frustration and coke emotions. At this stage, it is best to use several simple paragraphs to describe your own system, then expand around them, add some "noun" and "verbs". "Noun" naturally became an object, and "verb" naturally becomes a "method" to be integrated into the object interface. As long as you try to do it, you will find how useful tools; sometimes, it can help you complete the vast majority of work. Although it is still in the primary stage, some schedules at this time may also be used very well. We should now have a more comprehensive understanding of things that you have to build, so it may have felt that it will spend how long it will do. At this point, we must consider a large factor: if you estimate a longer schedule, then the company may decide no longer continue; or a supervisor has estimated this project to spend more time, and will try to affect you Estimate. But in any case, it is best to draft a "honest" schedule from the beginning, and then make some temporary difficult decisions. There are many technologies to help us calculate accurate schedule (just like techniques that predict stock market landing), but usually the best ways still rely on their own experience and intuition (don't forget, I don't want to build in experience) . I feel about it takes more time, and then doubles this time, plus 10%. Your feelings may be correct; "Maybe" can be done in that time. But "Double" makes that time, "10%" time is used to carry out the final scrutiny and deepening. But at the same time, it is necessary to make an appropriate explanation to the superior supervisor, regardless of the complaints and modifications of the other party, as long as it tells them: such a schedule, just one of my estimates! Stage 2: How to build? At this stage, a set of design must be taken and explain what the various objects contained in appearance are like, and how to communicate with each other. At this point, you can consider using a special chart tool: "Unified Modeling Language" (UML).
Please download a UML specification to http://www.rational.com. As the description tool in the first phase, UML is also very helpful. In addition, it is also possible to handle some charts (such as flowcharts) in the second phase. Of course, it is not necessary to use UML, but it will be helpful to you, especially when you want to draw a detailed chart, so many people study together. In addition to UML, you can also choose to serve the object and their interfaces (just like I said in "Thinking In C ", but this method is very primitive, and it is also a limited role. I have once again A very successful consultation experience, it involved a group of people's initial design. They have not built OOP (object-oriented programming) projects, draw objects on the whiteboard. We talk about how to communicate between each other. Communication), and delete some of them, and replacing another part. This group (they know what the purpose of this project) actually developed a design; they "own" design, not to design Naturally, it is naturally revealed. The things I have done there are guidance for design, put forward some appropriate issues, try to make some assumptions, and get feedback from the group to modify those assumptions. The most wonderful thing in this process is the entire group It is not to learn some abstract examples to perform object-oriented design, but through practical design to master OOP tricks, and that design is the work in his hand! Make an object and their interface. After the description, the work of the second phase was completed. Of course, these work may not be complete. Some work may wait until the phase 3 can be learned. But this is enough. We really need to care about all Object. It can be found earlier, but OOP provides a sufficiently perfect structure, and then find out that they are not late. Phase 3: Start to create a book, you may be a programmer, now you can enter, you may be the most Interested in the stage. Because there is a plan on the hand - how briefly it is, and in front of the official code, you will find that the next work will be more much more simpler than the beginning of the start. And this is the purpose we want to achieve. Let the code do what we want to do, this is the final goal of all program projects. But don't worry, otherwise it will only have to get lost. According to my experience, finally take out one Set of comprehensive programs, make it as much as possible to meet as much as possible. Give me the feelings, programming is more art, can't just be treated as a technology. All pay will eventually get a return. As a real Programmer, this is not a good quality. Comprehensive thinking, careful preparation, good structure not only makes the program more easily and debug, but also makes it more easily understood and maintained, but it is a software profit The necessary conditions. After building a good system, after running it, the actual inspection must be performed. The previous needs analysis and system specifications can be used. Comprehensively investigate their own procedures, and all the required requirements have been made Satisfied now? Is it true now? Is it? Stage 4: Time, the entire development cycle is not over, now it is a stage called "maintenance" in the traditional sense. "Maintenance" is a more embarrassing The title, Use it to "maintain it according to the way to operate", "join customers from the previous forgetting the declaration" or more traditional "off exposed all bugs" and so on.
Therefore, everyone has a lot of misunderstandings about the word "maintenance", and some people think that things that need "maintenance" must not be good, or have a defect! Because this term means that you actually build a very "original" program, you need to make changes frequently, add new code or prevent it from backward, degrade. Therefore, we need to continue working with a more reasonable word. This word is "reform". In other words, "The first thing you have done is not perfect, so you need to leave a deep study, a cognitive space, and then go back to make some changes." For problems to be solved, with the more deep depth of learning and understanding, it may be necessary to make a lot of changes. One of the powers of doing these work is to optimize the reform, and finally be rewarded from their own efforts, regardless of this requires a shorter or longer period. When is it called "to achieve the ideal state"? This does not only mean that the program must work as required, and can adapt to various designated "use conditions", which also means that the internal structure of the code should be perfect. At least, we should feel that the entire structure can be well coordinated. Without a clumsy grammar, there is no bloated object, and there is no other thing. In addition, it is necessary to ensure that the program structure has strong vitality. Due to many reasons, the changes to procedural changes are essential. However, it must be determined that the change can be easily and clear. There is no shortage here. Not only do you need to understand what you build, but also understand how the procedure continues to evolve. Fortunately, object-oriented programming languages are especially suitable for such continuous modifications - the boundaries established by the object can effectively ensure the overall structure of the structure, and prevent unrelated objects that have unrelated objects, destruction. You can also do some intense changes to your own procedures, and do not destroy the overall performance of the program, and will not affect other code. In fact, the support of "Calibration" is a very important feature of OOP. Through the correction, you can create things that are close to your own ideas. Then observe your own work from the whole, and compare it to your own requirements. Then you can go back and go back, redesign and re-implement inappropriate part of the program (annotation ⑩). Before you finally get a proper set of programs, you may need to solve some problems that cannot be avoided, or at least one aspect of the problem. And it is generally more "to reform" several times. When building a system, "the school" is almost inevitable. We need to constantly compare our needs and understand whether the system needs it actually. Sometimes only actually see the system, you can realize that you need to solve a different problem. If you think this form of the school will inevitably happen, then it is best to take out your own first version as soon as possible, check if it is hopeful, so that your mind continues to mature. Repeated "Calibration" related to "incremental development" related to the secret relationship. Increasing development means first starting from the core of the system, implementing it as a framework, and then gradually establishing the remaining parts of the system on this framework. Subsequently, the various functions (characteristics) that are ready to be provided will be added one. The most test skill here is that the racks set a framework that can easily expand all target features (for this issue, you can refer to Chapter 16). The advantage of this is that once the core frameworks work, each feature to join is like a small project in itself, not a part of the big project. In addition, new features in development or maintenance phase can be added more conveniently. OOP provides support for incremental development because, if the program is designed, each increment can be a perfect object or object group. ⑩: This is a bit similar to "fast shape". At this point, you should focus on building a simple, clear version, so that you can have a clear grasp of the system. Then throw this prototype and officially build one.
