【導(dǎo)讀】人們的親睞，成為人們生活中重要的組成部分。本系統(tǒng)是開(kāi)發(fā)一個(gè)用VB來(lái)開(kāi)發(fā)。的功能齊全具有實(shí)用價(jià)值的?桌面日歷型備忘錄管理軟件?，具有良好的應(yīng)用和。維護(hù)界面，也很容易實(shí)現(xiàn)。采用VB不僅大大的簡(jiǎn)化了數(shù)據(jù)庫(kù)的管理，使用戶(hù)可。以充分的利用系統(tǒng)提供的可視化工具和幫助菜單快速的，多條件查詢(xún)。品質(zhì)量與配臵管理之間的矛盾不是很突出，軟件產(chǎn)品本身規(guī)模不大，工操作即可滿(mǎn)足軟件管理的要求。質(zhì)量控制難以保證。此外，用手工記錄的這種方式存在著如下方面的。示方式，皮膚等。查詢(xún)，如關(guān)鍵字，日期等。日常維護(hù)的簡(jiǎn)易性，降低維護(hù)成本。硬件及軟件資源，以最少的人力投入完成系統(tǒng)的設(shè)計(jì)目標(biāo)。它能觀測(cè)企業(yè)或組?？椀母鞣N運(yùn)動(dòng)情況，利用過(guò)去的數(shù)據(jù)預(yù)測(cè)未來(lái)；從全局出發(fā)輔助決策；利用信息控制企業(yè)或組織行為，幫助其實(shí)現(xiàn)長(zhǎng)遠(yuǎn)的規(guī)劃目標(biāo)。這三打支柱稱(chēng)為管理信息系統(tǒng)的擴(kuò)展部件。把設(shè)計(jì)轉(zhuǎn)變?yōu)閷?shí)際的數(shù)據(jù)庫(kù)，并且這些數(shù)據(jù)庫(kù)帶有功。能完備、高效能的應(yīng)用。

　　

【正文】 roject into its ponent parts?) What are their interfaces? (What messages do you need to be able to send to each object?) If you e 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 can’t get away with any less. The process can be undertaken in five phases, and a phase 0 that is just the initial mitment to using some kind of structure. Phase 0: Make a plan You must first decide what steps you’re going to have in your process. It sounds simple (in fact, all of this sounds simple) and yet people often don’t make this decision before they start coding. If your plan is “l(fā)et’s jump in and start coding,” fine. (Sometimes that’s appropriate when you have wellunderstood 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 it’s done.” This can be appealing for awhile, but I’ve 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 bitesized 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 puters the structure is clear enough so that I don’t think much about it. But I still structure my work, albeit only semiconsciously 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 statement Any system you build, no matter how plicated, has a fundamental purpose, the business that it’s in, and the basic need that it satisfies. If you can look past the user interface, the hardware or systemspecific details, the coding algorithms and the efficiency problems, you will eventually find the core of its being, simple and straightforward. Like the socalled 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。 it’s a mission statement. You won’t necessarily get it right the first time (you may be in a later phase of the project before it bees pletely clear), but keep trying until it feels right. For example, in an airtraffic control system to a very small airfield。 perhaps there’s only a human controller or none at all. A more useful model won’t concern the solution you’re creating as much as it describes the problem: “Aircraft arrive, unload, service and reload, and depart.” Phase 1: What are we making? It’s necessary to stay focused on the heart of what you’re trying to acplish 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 you’ll 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 autoteller, for example, the use case for a particular aspect of the functionality of the system is able to describe what the autoteller 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 there’s 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 you’ve 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 aren’t 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 won’t get it all figured out perfectly on the first try, but that’s OK. Everything will reveal itself in time, and if you demand a perfect system specification at this point you’ll get stuck. Phase 2: How will we build it? In this phase you must e 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 ClassResponsibilityCollaboration (CRC) card. Part of the value of this tool is that it’s so lowtech: 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 writ