OO design process: start design software a teaching project
Allen Holub written editor, JavaWorld 2000 August 2000
Content: OO Demand Collection Problem Specification Refined Your Manual Questions and Solutions Details before Coding Conclusion Reference About the author
We have talked about how to distinguish between design procedures in July. This month, I will set up a software. I hope that the project should not be too trivial but very simple, so that we can complete it in a relatively reasonable time. I need a real program, not just a pure teaching practice. In this article, I adopted a teaching software. In the next few months, I will demonstrate the full design and (Java) implementation of this program, you will be able to see the entire process, from the beginning until the end. At the same time, I (special) has no errors during the editing process so that you can see everything happen. let's start.
OO needs Collection I have seen a statistics, 60% of the edited procedures were discarded within a few months per year, which is not because the program does not implement its task, but because it does not implement any useful s things. Of course, the productivity caused by this is greatly amazing. In addition, most of the code generated is very formal - they have a lot of documents, in order to complete what they want. Obviously, they did not work (see the editorials of Steve McConnell in the reference), which is also very obvious, no design, and continue to work. If calculating the failure rate of high-tech startup, I guess this percentage now or even It is higher than 60%.
One of the main reasons for failure is that most programmers do not have a clear idea that they will do in the software development process. For a useful program, you must ask those who will use the program, the program must do. However, this step is often ignored. Instead, he is just looking for a real user's agent (such as sales staff) to try to fiction what the so-called needs they call them. In fact, the programming designer needs to communicate frequently, but in this case the user is not possible to let the program designer understand what they need. So, our primary task is to solve what you must do, not how to do it. (Most programmers will immediately concentrate on how to do: What database? What kind of data model? What kind of UI? What is the data structure? This is now how unrealistic - first inhibit it first This impulse!)
In the OO statement, the first step in the problem is called a formal problem manual, and it is our task in the next few months.
In the system, the problem manual often ignores the collection of needs. I prefer to define this term with the problem, because "demand collection" usually contains some incorrect assumptions about the demand and how you go to collect it, etc. (at least from the OO angle). During the traditional processing, the functional requirements for functionality are often formed according to the functions provided by some third parties, such as the market sector. In fact, this demand is false, you can't control it. You will find this type of document in the OO environment - especially the function list - almost worthless. "Functional Needs" for providing algorithms and specified performance requirements For 00 delivery is a useful appendix, and they are not the most central. "Functional Demand" specifies the UI behavior, workflow, etc., why we explain the next few months.
Problem Instructions In any design, the problem is accurately stated in the first step. Here, your goal is to make a concise and accurate manual you have to solve the problem. Reaffirming again that your attention should be doing and why do it, not how to do it. Before you explain the problem, you must first understand the knowledge of this problem. Although each design group will have an expert (ideal is the end user) but other members of the design group must understand the knowledge in the field, although not necessarily as an expert. When you talk to the professional vocabulary in this field, you should have enough knowledge in this area without having to stop to explain the basic concept. Therefore, there is a research phase before starting the design item. If you are designing a accounting program to participate in the Accounting 101 of local intermediate colleges. Reaffirming again that you don't necessarily have to be an expert, because it is your user's work, and you must do with experts from the field without this knowledge, you don't even know what is your problem or how Ask them. Refining your manual's instructions should be fine, this is the key to success or failure of the design. Don't do the work of those fine branch, because they can hardly grasp the subtle things that reflect the problem. If you can't organize a good language with a clear, you can organize it, then the problem you understand is not enough to make you design anything. Good grammar is also crucial; it provides a good structure and precise method, otherwise it will make the idea to be a mess. In any design group, an excellent copy editor is also very important. There are also some about the writing process itself - that is, the exact language, but there is no need in the conversation - this can help you find new aspects of the problem. I found that when I first wrote all the questions and then started coding, I won't be difficult by some things. If you write a comment before encoding, the encoding will be rapid and there is a few errors in the code. The issues you want to discuss must be expressed in all the terms of the problem. If you want to solve the accounting problem, the problem manual should completely use the vocabulary in accounting. That is to say, any competent accountant should understand the instructions of the problem, and do not ask some questions. With regard to the integrity of design, a headless parallel can fully understand the specific issues to be solved and the general solution to the specific issues to be solved by browsing the documents that are familiar with those skilled in this area. If this level understands cannot be implemented, the design is incomplete. I can't emphasize the problem instructions is not a discussion of computer programs. The problem specification should involve the problem itself, not the problem based on computer-based solution. What we have to discuss is the problem that your end user in the real world is going to solve. Words such as "Computers", "Menu", "Dialog", "Internet" and "Internet" should not appear here. The problem is never included in: "System must be ..." or "We write a computer program ..." written computer programs may be your business, but your end user is concerned about the problem, but it is very little involving computer (although they Perhaps this solution may be involved). Most problems can be described well without computers, although the computer may solve faster or easier. Although you must ultimately prepare a description based on computer solutions, so far, our focus is part of the documentation. Remember that there is no computers in the computer here, any accountant should clearly understand the provisions of the accounting field written by the programmer.
As much as possible, the solutions and solutions as part of the problem, as part of the problem, should be discussed. All OO systems must be modeled. If there is a good solution, the reality is that people cannot perform existing solutions quickly, then modeling existing solutions. That is, manual process automation is all necessary, and your question guide should completely describe the manual process.
In the question guide, an important thing to confirm is the user's goal. What is the user to complete? The user's goal fully affects the direction of the solution. (For example, your goal is to plan a meeting or maintenance of a calendar? In the first case, you may see the place similar to the traditional calendar in the program is in the output .alan cooper, in his About Face this book It is called the "design of the guide" (see Resources) (see Resources) You must also explain the desired results. What is the final result of solving the problem? What information does the final result express? (Note in this stage Interested is the content of this information, rather than physical layouts or content expressions.)
Ignore the existence of the old system as much as possible. The user's goal is rarely improved the old system. Instead, the user is to complete work, and because the old system cannot work by you. Let us start from the beginning.
Do not try too formal in the problem rule. Just describe what you want to do, just like you are talking to a partner. (I often ask "What do I say?" My answer is always, "I like that - you said."
The next step, and the real users and experts in the field have just defined issues. Then, use vocabulary in this field to explain the problem, let your users look at the problem manual to make sure you are correct. Here I think it can jump through the talks, because I am an expert (parent), I will start it directly. The results prove that this shortcut taken is wrong, I will discuss this problem in the next month.
So let us start
One of the best ways to teach children how to manage money (also a very interesting job) is to establish a bank account for them. However, it is said that the real bank will not pay a lot of interest to meet the interest of children. (After all, the general annual interest rate is 3.5%, and the interest obtained by 20 US dollars is up to $ 0.72). I get a revelation from the "MarketPlace," program of NationalPublic Radio, decided to open a bank of allen (or Bofa), and its monthly interest rate is 5% (indeed 5% each month - 60% per year) but daily Calculate. According to this interest rate of Bank Of Allen, $ 15.91 can be earned after a year. Despite this high interest rate, Bank of Allen still operates like a real bank. Children have their own accounts, on this account, in addition to interest rates, they can do anything. They can view (or print) all at any time. They can access casually. In order to improve the interest of children, the passbook must let the children look to show how many interests have earned except for general accounts (save, taking and balance). Children must be interested in assumptions: If I don't take a penny for two months, how much will it? This shows you that you don't spend money and make money. There are also several security issues here. Only banks (ie, parents) can change interest rates or establish new accounts (and initial balances). Like real banks, children can't save money or pay by tampering with their passbooks, they must let banks do this; bank handle transactions and update passbooks. That is, the child handed the money to the bank, and the bank put the money into its account. Bank extracts money from the account and divides it with your child. (In fact, this means that only parents can save money or pay money, but this is a request for the children to take money or think that the bank is using this money and makes them not get their own money.) Goals ( Arranged by importance): Teaching children to save money showing "Bank of Allen" is a trademark of Allen I. Holub. This program and related design are (c) 2000, Allen I. Holub. All rights reserved.
I don't think this problem is complete, it is just a beginning. In general, if some appropriate issues have not been expressed, the instructions of the problem are incomplete. More typical is a large number of details. For a small program - probably takes 6 people to spend 8 months time - after all the details are resolved, its problem manual is easy to reach around 80 pages. So, it is clear that I have done so far.
The details of the details before the encoding are to consider many details as much as possible before the coding begins. Don't try to leave the details to the truly start coding. Don't whims you you can solve all your problems in advance. Unless you work in a very quiet night. Solving all the details in advance is almost impossible. In any case, the end user will find some problems they have not considered when the system is transformed into results and starts. This is normal, and any design methods cannot be dealt with later, so that the design method is very fragile in most programming environments. In fact, then, when designing and execution, the definition of the problem will change. That's why there is an end user reason in the design team: to make sure you don't destroy some things because of improving them. Even so, the initial problem definition should be as detailed. Write all what you think on paper. Don't miss any details, even easier. Teaching members through their OO design is one of my livelihoods, but they often invite me when they have begun to design. Usually, I let my customers give me their design documents, so I can prepare our first talks, and it is much better. I was told me to go and speak to make me fully understand what the problem is. Those who replied back to me some reminders. If the problem is not written down and a foreman can understand the problem through reading, then I know that the understanding of the customer may not start design. Although I believe in the existence of "Analysis Failed", I have never seen it; the opposite, I have seen it in contrast: programmers entered the encoded state in prematurely, but not fully analyzed. Go back and see the initial problem manual, you will notice that I have not mentioned anywhere. I am now describing the problem, not a computer program. Here, the problem is to raise, not banks. Therefore, the manual is written to the parent, not a banker. Also pay attention to the use of relatively simple sentences. Avoid using passive voice and academic literature, which is a disaster for users. The simple sentence (subject / predicate / direct object) determines the main body of the behavior (subject), execution action (predicate), and information recipient (direct object) of the requesting action. The passive voice only involves the rear of these three parts. Whenever I use "I", "You", etc., it will do it. The end of this month is here. We have opened a head - identified basic problems. Next month, I will continue this lecture, refine the rule manual, so that it can be used effectively.
Reference
Please read the editorial of IEEE Software from March / April 2000 Journal of Documents. This editorial "Cargo Cult Software Engineering" is written by Steve McConnell. For more information about UI design, see About Face: The Essentials of User Interface Design writes by Alan Cooper (IDG Press). Coincidental, this book about UI design is also the "Visual Basic's Father" - the tool is the cause of many worst user interfaces to cause chaos of the computer world. Cooper has a lot of views, some of which I agree, and some I don't agree. (Especially if I think the procedure as a UI should not have intelligent flaws to hang the program). Despite this, Cooper still has many good insights to make people interested.
I found that most books about UI design are programmers (they put programmers on the user's needs) or artist (they put art, effect, and creative on user needs). No matter which case, the user has been abandoned. So, the UI book that is like reading is written by the experienced programmer. He not only puts the user first, but also has a good design awareness. Cooper Design website, from Cooper Design "Manifesto": In fact, most software today has such an interface:
About the author Allen Holub works since 1979. He published articles in many magazines (Dr. Dobb's Monthly, Programmer Month, Byte, MSJ, and other magazines), and he is the editor of online magazine Javaworld. He has eight books that are appreciated, and the latest one (Taming Java Threads) tells the trap and defects of the Java thread. He has been engaged in designing and building an object-oriented software for a long time. After 8 years of C programmers, Allen gave up C steering Java program in early 1996. He has been teaching programming for Berkeley in 1982 (first C, then C and MFC, now OO design and Java programming). Allen provides Java technology and object-oriented public curriculum and specialized training. He also conducts object-oriented design consultation and commercial Java programming. Please visit Allen's website www.holub.com.
