Program | Programmers should be familiar with these two words, but the meaning contained in the word may not be particularly clear. First of all, it must be explained that programmers and system analysts do not exist who senior who is inferior to the difference, they are two professions, the requirements of professional skills are completely different. So it's wrong to say that a powerful programmer is a system analyst. Of course, the system analyst's skills require him to know how to write a program, but his focus is on how to cut a large project into small pieces that fit the individual, and then organize the small pieces. The responsibility of the programmer is to realize these small pieces better and faster.
Before this chapter, we were talking about the skills that a qualified programmer should have, and certainly not just that. The reason we're here to talk about system analysts is because our columns are called Software engineering, not programmers from getting started to being proficient.
Before we begin, we'll look at the author's insightful insights into analysis and design in the thinking in Java:
Analysis and Design
The object-oriented paradigm is a new and radically different way of thinking about programming, and many people begin to frown on how to construct a project. In fact, we can make a "good" design that leverages all the benefits that OOP offers.
Excuse me, here comes the word oop, which he means is the object of the face, although not mentioned before, but in the current world of OO concept, people should not be too unfamiliar to him. Here I give a brief explanation. In fact, I've been talking about the experience of writing a long time ago (what, teach us antiques, beat him!). , but the previous non-OO (process-based) software design approach is now rarely adopted internationally, so I'm talking about software design when all the concepts are based on OO. Even if the concept of OO is very simple, think about it, we learn C + + when the first use of the class is not some animals, squares, and so on, are examples of life, right. Oo is actually the way we look at the world. But the first because of the underdevelopment of computer technology, we have to use some very strange description to express our meaning, only so that the computer can understand, very stupid is not it. For example, we must use parameters, procedures, functions. So the software design method at that time is based on the process. Give a simple example to show the difference between OO design methods and process based design methods: a simple daily phrase-"I eat", the use of Oo method to express or "I eat", but if the process based on the description of the word will become "I eat (rice)" is not very awkward. If you think you have any questions about Oo, look at another topic under the Software Engineering column: "Thinking in Java appreciation"
Most of the books on OOP analysis and design are unsatisfactory. Most of these books are filled with inexplicable words, clumsy style, and a lot of statements that seem to be important. I think this kind of book is best compressed into a chapter or so in the space, at most a very thin book. Ironically, those who specialize in the management of complex things tend to have a lot of trouble writing plain, clear books. If you can not speak simple and direct, not many people like to see this aspect of the content. After all, the whole purpose of OOP is to make the process of software development easier. While this may affect the livelihoods of those who like to solve complex problems, why not make things simpler from the start? Therefore, I hope I can lay a good foundation for everyone from the beginning, as far as possible in a few paragraphs to clear analysis and design problems.
Don't get lost.
In the whole development process, the most important thing is: do not lose yourself! But in fact this kind of thing is very easy to happen. Most of the methods are designed to solve the maximum range of problems. Of course, there are also some particularly difficult projects that require the author to make more strenuous efforts, or pay a greater price. However, most projects are relatively "conventional", so it is generally possible to make a successful analysis and design, and only use a small number of recommended methods. But no matter how limited, some forms of processing are always beneficial, which makes the development of the whole project easier, always more straightforward than when the start code is good!
That is, if you're looking at a particular method that contains a lot of detail and recommends a lot of steps and documents, it's still hard to tell exactly when to stop. Always remind yourself of the following questions:
(1) What is the object? (How do you split your project into a series of separate components?) ）
(2) What are their interfaces? (What message would you need to send to each object?) ）
Once you have identified the objects and their interfaces, you can start writing a program. For many reasons, more explanations and documentation may be required, but there is absolutely no need for more information than this.
The entire process can be divided into four phases, and phase 0 is just beginning to take on some form of structure.
Phase 0: Draw up a plan
The first step is to decide which steps to take in the subsequent process. This may sound simple (in fact, everything we say here seems simple), but it's a common case that some people don't even get into stage 1 and are busy 慌慌 to start writing code. If your plan was to "start coding directly", that would certainly be beyond reproach (consider doing so if you have a thorough understanding of the problem you are trying to solve). But the minimum should also agree that you should have a plan.
At this stage, you may want to decide on some of the additional processing structures that are necessary. Unfortunately, some programmers like to do whatever they want when they write a program, and they think "it's done naturally." This may not be a problem at first, but I think it would be better for you to focus if you can set a few signs or "signposts" throughout the process. This is probably much better than simply working to "get the job done". At least, in the attainment of one after another goal, after one after another road signs, can have a clear grasp of their progress, the drive will be correspondingly improved, will not produce "road remote long" feeling.
Since I began to learn the structure of the story (I would like to write a novel one day), I have always adhered to this practice, feeling like simply let the words "flow" to the paper. When I write about computer things, I find that the structure is much simpler than fiction, so there is no need to think too much about it. But I still worked out the whole structure of the writing so that I had a pretty idea of what to write. So, even if your plan is to start writing programs directly, you still need to go through the following stages and ask yourself some specific questions.
Phase 1: What to make?
In the previous generation of programming (that is, "procedural or programmatic design"), this stage is called "Building requirements analysis and system specifications." Of course, those operations are no longer needed today, or at least changed in form. A lot of headache documents have become history. But the original intention was good. The meaning of requirement analysis is "to establish a set of rules based on which to judge when a task is to be completed, and how the customer is satisfied". The system specification says "Here are some specific instructions that let you know what the program needs to do (rather than how) to meet the requirements." Requirements analysis is actually a contract between you and the customer (even if the customer is working within the company, or other objects and systems). The system specification is the highest level of revelation of the problem that we are facing, based on which we judge whether the task is complete and how long it will take. Since these all require the unanimous consent of the participants, I suggest simplifying them as much as possible-preferably in the form of lists and basic charts-to save time. There may be other constraints that need to be expanded into larger documents.
We should pay particular attention to focusing on the core issues at this stage and not dwell on the minutiae. The central question is: decide what system to use. The most valuable tool for this problem is a collection called "Usage criteria." What should the system do with "if ...?" This is the most persuasive answer to the question of form. For example, "if a customer needs to withdraw a cash cheque, but there is not so much cash reserve, then how should the ATM respond?" "On this issue," conditions of use can instruct the ATM to operate correctly under that "condition".
As far as possible, the system should be summed up a complete set of "use conditions" or "application situation." Once this work is done, it is a key task to get the system done. One good thing about focusing on "use conditions" is that they always let you focus on the most critical things and prevent yourself from being distracted by other things that don't have much to do with the task. That is, as long as you have a complete set of "usage conditions", you can make a clear description of your system and move on to the next stage. At this stage, it may not be possible to fully grasp the future applications of the system, but it does not matter. If you take the time, all the problems will be revealed naturally. Do not too much care about the system specifications of the "perfect", otherwise it is easy to create frustration and scorched mood.
At this stage, it's a good idea to describe your system in a few simple paragraphs and then expand around them to add some "nouns" and "verbs." "Nouns" naturally become objects, and "verbs" naturally become "methods" to be integrated into the object interface. As long as you try to do it yourself, you will find how useful it is, and sometimes it can help you do most of the work.
While it is still in its infancy, some of these schedules can be very useful. We now have a more comprehensive understanding of what we want to build, so we may have sensed how long it would take to complete. There are a number of factors to consider: If a longer schedule is estimated, the company may decide not to go on, or a supervisor has already figured out how long the project will take and try to influence your estimate. However, it is better to draw up an "honest" timetable from the outset and make some decisions that are temporarily difficult to make. There are a number of technologies that can help us figure out the exact schedule (like those that predict the stock market's ups and downs), but the best way to do it is to rely on your own experience and intuition (don't forget that intuition is based on experience). Feel about how long it will take, then double this time, plus 10%. Your feelings may be correct, and "maybe" can be done in that time. But "doubling" makes that time more plentiful, and "10%" time is used for final scrutiny and deepening. But at the same time also to the superior to make appropriate explanations, regardless of what the other party complained and modified, as long as the clear to tell them: such a schedule, just one of my estimates!
Phase 2: How to build?
At this stage, you have to come up with a design and explain how the various objects in it look and how they communicate with each other. Consider using a special charting tool: "Unified Modeling Language" (UML). Please go to http://www.rational.com to download a UML specification book. As a description tool in phase 1th, UML is also helpful. In addition, it can be used to process some charts (such as flowcharts) in phase 2nd. Of course you don't have to use UML, but it will help you a lot, especially if you want to paint a detailed chart that allows many people to study together. In addition to UML, you can choose to have a textual description of objects and their interfaces (as I said in the thinking in C + +), but this approach is very primitive and has a limited role to play.
I had a very successful consulting experience at that time involving the initial design of a small group of people. They have not previously built OOP (object-oriented programming) projects, drawing objects on the whiteboard. We talked about how each object communicates (communicates), deletes part of it, and replaces another part of the object. The team (they know what the purpose of the project is) has actually worked out the design, and they themselves "own" the design, rather than letting the design manifest itself naturally. What I do there is to guide the design, ask some appropriate questions, try to make some assumptions, and get feedback from the group to modify those assumptions. The most wonderful thing in the process is the whole little
