java教学评价管理系统毕业设计英文文献翻译.doc

毕业设计说明书英文文献及中文翻译学生姓名： 学号： 学 院： 专 业： 指导教师： 2014 年 6 月On the software developmentWhile youre going through the development process, the most important issue is this: Dont get lost. Its easy to do. Most of the analysis and design methods are intended to solve the largest of problems. Remember that most projects dont fit into that category, so you can usually have successful analysis and design with a relatively small subset of what a method recommends. But some sort of process, no matter how limited, will generally get you on your way in a much better fashion than simply beginning to code.Its also easy to get stuck, to fall into “analysis paralysis,” where you feel like you cant move forward because you havent nailed down every little detail at the current stage. Remember, no matter how much analysis you do, there are some things about a system that wont reveal themselves until design time, and more things that wont reveal themselves until youre coding, or not even until a program is up and running. Because of this, its crucial to move fairly quickly through analysis and design, and to implement a test of the proposed system.This point is worth emphasizing. Because of the history weve had with procedural languages, it is commendable that a team will want to proceed carefully and understand every minute detail before moving design and implementation. Certainly, when creating a DBMS, it pays to understand a customers needs thoroughly. But a DBMS is in a class of problems that is very well-posed and well-understood; in many such programs, the database structure is the problem to be tackled. The class of programming problem discussed in this chapter is of the “wild-card” (my term) variety, in which the solution isnt simply re-forming a well-known solution, but instead involves one or more “wild-card factors”-elements for which there is no well-understood previous solution, and for which research is necessary. Attempting to thoroughly analyze a wildcard problem before moving into design and implementation results in analysis paralysis because you dont have enough information to solve this kind of problem during the analysis phase. Solving such a problem requires iteration through the whole cycle, and that requires risk-taking behavior (which makes sense, because youre trying to do something new and the potential rewards are higher). It may seem like the risk is compounded by “rushing” into a preliminary implementation, but it can instead reduce the risk in a wild-card project because youre finding out early whether a particular approach to the problem is viable. Product development is risk management.Its often proposed that you “build one to throw away.” With OOP, you may still throw part of it away, but because code is encapsulated into classes, during the first iteration you will inevitably produce some useful class designs and develop some worthwhile ideas about the system design that do not need to be thrown away. Thus, the first rapid pass at a problem not only produces critical information for the next analysis, design, and implementation iteration, it also creates a code foundation for that iteration.That said, if youre looking at a methodology that contains tremendous detail and suggests many steps and documents, its still difficult to know when to stop. Keep in mind what youre trying to discover:What are the objects? (How do you partition your project into its component parts?)What are their interfaces? (What messages do you need to be able to send to each object?)If you come up with nothing more than the objects and their interfaces, then you can write a program. For various reasons you might need more descriptions and documents than this, but you cant get away with any less.The process can be undertaken in five phases, and a phase 0 that is just the initial commitment to using some kind of structure.Phase 0: Make a planYou must first decide what steps youre going to have in your process. It sounds simple (in fact, all of this sounds simple) and yet people often dont make this decision before they start coding. If your plan is “lets jump in and start coding,” fine. (Sometimes thats appropriate when you have well-understood problem.) At least agree that this is the plan.You might also decide at this phase that some additional process structure is necessary, but not the whole nine yards. Understandably enough, some programmers like to work in “vacation mode” in which no structure is imposed on the process of developing their word; “It will be done when its done.” This can be appealing for awhile, but Ive found that having a few milestones along the way helps to focus and galvanize your efforts around those milestones instead of being stuck with the single goal of “finish the project.” In addition, it divides the project into more bite-sized pieces and makes it seem less threatening (plus the milestones offer more opportunities for celebration).When I began to study story structure (so that I will someday write a novel) I was initially resistant to the idea of structure, feeling that when I wrote I simply let it flow onto the page. But I later realized that when I write about computers the structure is clear enough so that I dont think much about it. But I still structure my work, albeit only semi-consciously in my head. So even if you think that your plan is to just start coding, you still somehow go through the subsequent phases while asking and answering certain questions.The mission statementAny system you build, no matter how complicated, has a fundamental purpose, the business that its in, and the basic need that it satisfies. If you can look past the user interface, the hardware- or system-specific details, the coding algorithms and the efficiency problems, you will eventually find the core of its being, simple and straightforward. Like the so-called high concept from a Hollywood movie, you can describe it in one ore two sentences. This pure description is the starting point.The high concept is quite important because it sets the tone for your project; its a mission statement. You wont necessarily get it right the first time (you may be in a later phase of the project before it becomes completely clear), but keep trying until it feels right. For example, in an air-traffic control system to a very small airfield; perhaps theres only a human controller or none at all. A more useful model wont concern the solution youre creating as much as it describes the problem: “Aircraft arrive, unload, service and reload, and depart.”Phase 1: What are we making?Its necessary to stay focused on the heart of what youre trying to accomplish in this phase: determine what the system is supposed to do. The most valuable tool for this is a collection of what are called “use cases.” Use cases identify key features in the system that will reveal some of the fundamental classes youll be using. These are essentially descriptive answers to questions like:“Who will use this system?”“What can those actors do with the system?”“How does this actor do that with this system?”“How else might this work if someone else were doing this, or if the same actor had a different objective?”(to reveal variations)“What problems might happen while doing this with the system?”(to reveal exceptions)If you are designing an auto-teller, for example, the use case for a particular aspect of the functionality of the system is able to describe what the auto-teller does in every possible situation. Each of these “situations” is referred to as a scenario, and a use case can be considered a collection of scenarios. You can think of a scenario as a question that starts with: “What does the system do if?” For example, “What does the auto-teller do if a customer has just deposited a check within 24 hours and theres not enough in the account without the check to provide the desired withdrawal?”Use case diagrams are intentionally simple to prevent you from getting bogged down in system implementation details prematurely:The use cases produce the requirements specifications by determining all the interactions that the user may have with the system. You try to discover a full set of use cases for your systems, and once youve done that you have the core of what the system is supposed to do. The nice thing about focusing on use cases is that they always bring you back to the essentials and keep you from drifting off into issues that arent critical for getting the job done. That is, if you have a full set of use cases you can describe your system and move onto the next phase. You probably wont get it all figured out perfectly on the first try, but thats OK. Everything will reveal itself in time, and if you demand a perfect system specification at this point youll get stuck.Phase 2: How will we build it?In this phase you must come up with a design that describes what the classes look like and how they will interact. An excellent technique in determining classes and interactions is the Class-Responsibility-Collaboration (CRC) card. Part of the value of this tool is that its so low-tech: you start out with a set of blank 3” by 5” cards, and you write on them. Each card represents a single class, and on the card you write:The name of the class. Its important that this name capture the essence of what the class does, so that it makes sense at a glance.The “responsibilities” of the class: what it should do. This can typically be summarized by just stating the names of the member functions (since those names should be descriptive in a good design), but it does not preclude other notes. If you need to seed the process, look at the problem from a lazy programmers standpoint: What objects would you like to magically appear to solve your problem?The “collaborations” of the class: what other classes does it interact with? “Interact” is an intentionally broad term; it could mean aggregation or simply that some other object exists that will perform services for an object of the class. Collaborations should also consider the audience for this class. For example, if you create a class Firecracker, who is going to observe it, a Chemist or a Spectator? The former will want to know what chemicals go into the construction, and the latter will respond to the colors and shapes released when it explodes.You may feel like the cards should be bigger because of all the information youd like to get on them, but they are intentionally small, not only to keep your classes small but also to keep you from getting into too much detail too early. If you cant fit all you need to know about a class on a small card, the class is too complex (either youre getting too detailed, or you should create more than one class). The ideal class should be understood at a glance. The idea of CRC cards is to assist you in coming up with a first cut of the design so that you can get the big picture and then refine your design.One of the great benefits of CRC cards is in communication. Its best done real-time, in a group, without computers. Each person takes responsibility for several classes (which at first have no names or other information). You run a live simulation by solving one scenario at a time, deciding which messages are sent to the various objects to satisfy each scenario. As you go through this process, you discover the classes that you need along with their responsibilities and collaborations, and you fill out the cards as you do this. When youve moved through all the use cases, you should have a fairly complete first cut of your design.Before I began using CRC cards, the most successful consulting experiences I had when coming up with an initial design involved standing in front of a team, who hadnt built an OOP project before, and drawing objects on a whiteboard. We talked about how the objects should communicate with each other, and erased some of them and replaced them with other objects. Effectively, I was managing all the “CRC cards” on the whiteboard. The team (who knew what the project was supposed to do) actually created the design; they “owned” the design rather than having it giving it given to them.All I was doing was guiding the process by asking the right questions, trying out the assumptions, and taking the feedback from the team to modify those assumptions. The turn beauty of the process was that the team learned how to do object-oriented design not by reviewing abstract examples, but by working on the one design that was most interesting to them at that moment: theirs.Once youve come up with a set of CRC cards, you may want to create a more formal description of your design using UML. You dont need to use UML .but it can be helpful, especially if you want to put up a diagram on the wall for everyone to ponder, which is a good idea. An alternative to UML is a textual description of the objects and their interfaces, or, depending on your programming languages, the code itself.UML also provides an additional diagramming notation for describing the dynamic model of your system. This is helpful in situations in which the state transitions of a system or subsystem are dominant enough that they need their own diagrams (such as in a control system). You may also need to describe the data structures, for systems or subsystems in which data is a dominant factor (such as a database),Youll know youre done with phase 2 when you have described the objects and their interfaces. Well, most of them there are usually a few that slip through the cracks and dont make themselves known until phase 3. But thats OK. All you are concerned with is that you eventually discover all of your objects. Its nice to discover them early in the process but OOP provides enough structure so that its not so bad if you discover them later. In fact, the design of an object tends to happen in five stages, throughout the process of program development.Phase 3: Build the coreThis is the initial conversion from the rough design into a compiling and executing body of code that can be tested, and especially that will prove or disprove your architecture. This is not a one-pass process, but rather the beginning of a series of steps that will iteratively build the system, as youll see in phase4.Your goal is to find the core of your system architecture that needs to be implemented in order generate a running system, no matter how incomplete that system is in this initial pass. Youre creating a framework that you can build upon with further iterations. Youre also performing the first of many system integrations and tests, and giving the stakeholders feedback about what their system will look like and how it is progressing. Ide