英文材料

While yoursquo;re going through the development process, the most important issue is this: Donrsquo;t get lost. Itrsquo;s easy to do. Most of the analysis and design methods are intended to solve the largest of problems. Remember that most projects donrsquo;t 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.

Itrsquo;s also easy to get stuck, to fall into “analysis paralysis,” where you feel like you canrsquo;t move forward because you havenrsquo;t 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 wonrsquo;t reveal themselves until design time, and more things that wonrsquo;t reveal themselves until yoursquo;re coding, or not even until a program is up and running. Because of this, itrsquo;s 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 wersquo;ve 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 customerrsquo;s 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 isnrsquo;t 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 donrsquo;t 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 yoursquo;re 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 yoursquo;re finding out early whether a particular approach to the problem is viable. Product development is risk management.

Itrsquo;s 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 yoursquo;re looking at a methodology that contains tremendous detail and suggests many steps and documents, itrsquo;s still difficult to know when to stop. Keep in mind what yoursquo;re 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 canrsquo;t 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 plan

You must first decide what steps yoursquo;re going to have in your process. It sounds simple (in fact, all of this sounds simple) and yet people often donrsquo;t make this decision before they start coding. If your plan is “letrsquo;s jump in and start coding,” fine. (Sometimes thatrsquo;s 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 itrsquo;s done.” This can be appealing for awhile, but Irsquo;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 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 donrsquo;t 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 statement

Any system you build, no matter how complicated, has a fundamental purpose, the business that itrsquo;s 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 i

剩余内容已隐藏，支付完成后下载完整资料

当你在开发时，最重要的是：不要迷失。这是很容易做到的。大部分的分析和设计方法都是为了解决大部分的问题。记住这点，大多数的项目都不适合这一点，所以我们通常可以用一个相对较小的子集来成功地进行分析和设计。但是采用某种过程，无论它怎么有局限，总比一开始就直接编码好多了。它也非常容易受阻，陷入到“分析瘫痪状态”，这种状态往往是由于没有弄清当前阶段的所有细节而感到不能继续了。记住，不论做了多少分析，总有一些系统问题直到设计时才暴露出来，并且更多的问题是到编程或是直到程序完成运行适才出现。因此，迅速进行分析和设计并对提出的系统进行测试是很重要的。

这个问题值得强调。因为我们在面向过程型语言上的历史经验，一个项目组希望进入和实现之前认真处理和理解每个细节，这是值得赞赏的。的确，在构造DBMS时，需要彻底理解用户的需要。但是DBMS属于能很好表达和充分理解的一类问题。在许多这种程序中，数据库结构就是主要问题之所在。本章讨论的编程问题属于所谓的“不定（will card）”（本人的术语）类型，这种问题的解决方法不是将众所周知的解决方案简单地重组，而是包含一个或多个“不定因素”—先前没有较了解的解决方案的要素，为此，需要研究。由于在分析阶段没有充分的信息去解决这一类问题，所以在设计和执行之前试图彻底地分析“不定型”问题会造成分析瘫痪。解决“不定型”问题需要在整个循环中反复，且需要冒风险（这是很有意义的，由于是在试图完成一些新颖的且潜在回报很高的事情）。看来似乎有风险是由于“匆忙”进入初步实现而引起的，但是这样反而可以降低风险，因为我们正在较早地确定一个特定的方法对这个问题是不是可行的。产品开发也是一种风险管理。

经常有人提到“建立一个然后丢掉”。在OOP中，我们仍然可以把一部分丢掉，然而由于代码被封装成类，在第一次的迭代中我们必将生成一些有用的类设计，并且一些不必抛弃的关于系统设计的有价值的思想。因此，在问题的第一次快速遍历中不仅要为下一遍分析、设计及实现产生关键的信息，还为下一遍建立代码基础。

也就是说，如果我们正在考虑的是一个包含丰富细节且需要许多步骤和文档的方法学，将很难判断什么时候停止。应当牢记我们正努力寻找的是什么：

1． 什么是对象？(如何将项目分成多个组成部分？）

2． 它们的接口是什么？(需要向每个对象发送什么信息？）

只要我们知道了对象和接口，就可以编写程序了。由于各种的原因我们可能需要比这些更多的描述和文档，但我们需要的信息不能比这些更少。

整个过程可以分5个阶段完成，阶段0只是使用一些结构的初始约定。

阶段0：制定计划

我们必须首先决定在此过程中应有那些步骤。这听起来很简单（事实上，所有听起来都是挺简单的），但是人们常常在开始编码之前没有考虑这一问题。如果计划是“让我们一开始就编码”，那很好（有时，当我们对问题充分理解时，这是合适的）。至少，我们承认这是一个计划。

在这个阶段，我们可能还要决定一些另外的过程结构，但不是全部。可以理解，有些程序员喜欢用“休假方式”工作，也就是在开展他们的工作过程中，没有强制性的结构。“想做的时候就做”。这也许在短时间内是吸引人的，但是我发现，在进程中设立一些里程碑可以帮助集中我们的注意力，激发我们的热情，而不是只注意“完成项目”这个单一的目标。另外，里程碑将项目分成更细的阶段使得风险更小（此外里程碑还提供更多庆祝的机会）。

当我开始研究小说结构时（有一天我也要写小说），我最初是反对结构思想的，我觉得自己在写作时，直接下笔千言就行了，但是，稍后我认识到，在涉及计算机的文字时，本身结构足够清晰，所以不需要多想。但是我仍然要组织文字结构，虽然这在我头脑中是半意识的。即便我们认为自己的计划只是一上来就开始编码，在后续阶段仍然需要不断地询问和回答一些问题。

任务陈述

无论构建什么系统，不管如何复杂，都有其基本目的的，有其要处理的业务，有其所要满足的基本需要。通过依次审视用户界面、硬件或系统的特殊细节、算法编码和效率问题，我们将最终找出它的核心。通常简单又直接。就像来自好莱坞电影的所谓的高层概念，我们能用一句或两句话表述。这种纯粹的表述是起点。

高层概念很重要，因为它设定了项目的基调，这是一种任务陈述。我们不必一开始就让它正确（我们也许正处于在项目变得完全清晰之前的最后阶段），但是要不停地努力直到它越来越正确。例如：在一个空中交通指挥系统中，在一个空中交通管制系统到一个非常小的机场，也许只有一个人控制器或根本没有。 一个更有用的模型不会关心您创建的解决方案，因为它描述了问题：“飞机到达，卸载，服务和重新加载，并离开”。

第一阶段：我们在做什么？

在这个阶段，保持专注于你要完成的工作的核心是必要的：确定系统应该做什么。 对它而言最有价值的工具是所谓的“用例”的集合。用例识别系统中的关键功能，将揭示你将要使用的一些基本类。 这些是对以下问题的基本描述性回答：

“谁来使用这个系统？”

“这些演示者可以与系统做什么？”

“这个演示者怎么用这个系统呢？”

“如果别人这样做，或者同一个演示者有不同的目标，那么这个工作怎么办？”（揭示变化）

“使用系统执行此操作时可能会发生什么问题？”（显示异常）

例如，如果你正在设计自动柜员机，系统功能的特定方面的用例可以描述自动柜员在每种可能情况下所做的工作。这些“情况”中的每一个都被称为场景，并且用例可以被认为是场景的集合。你可以将一个场景看作是一个开始于“如果...，系统做什么？”的问题。例如，“如果一个客户在24小时内刚刚存了一张支票，那么自动柜员做什么呢？帐户没有支票提供所需的提款？”

用例图有意简化以防止系统实现细节过早陷入僵局：

用例通过确定用户与系统的所有可能的交互来产生需求规范。你尝试为你的系统发现一整套用例，一旦你完成你就掌握了系统的核心。关注使用案例的好处是它们总是让你重新掌握必要的内容，并使你不再纠结对完成工作不重要的问题。也就是说，如果你有一整套用例，您可以描述你的系统并进入下一个阶段。你可能不会在第一次尝试中完全弄清楚，但是没关系。如果你要求完美的系统规格，一切都会及时显现。

在这一点上，你会被卡住。

阶段2：我们将如何建立它？

在这个阶段，你必须想出一个描述类的样子和它们将如何交互的设计。确定类和互动的一个很好的技巧是类的原型（CRC）。这个工具的一部分价值在于它是如此的简单：你先从一张空白的3“times;5”原型开始，然后写上它们。每个原型代表一个单一的类，并且你要知道：

重要的是类的名称，这个名字可以看出类是做什么的，这将一目了然。

类的“责任”：应该做什么，通常只需说明成员函数的名称（因为这些名称在良好的设计中应该是描述性的），这通常可以归纳总结，但并不排除其他注释。如果你需要种子化过程，请从懒惰的程序员的角度来看待这个问题：你希望什么对象可以奇迹般地解决你的问题？

类的“合作”：与其互动的其他类有哪些？ “互动”是一个有意义的广义术语;它可能意味着聚合，或者简单地说，存在一些其他对象将为该类的对象执行服务。合作也应该考虑这个类的受众。例如，如果你创建一个类爆竹，谁来观察它，一个化学家或一个观众？前者会想知道什么化学品进入施工，而后者会响应爆炸时释放的颜色和形状。

你可能会觉得原型应该更大，因为你想要获得所有信息，但是它们是小小的，不仅要保持你的类小，而且还要让你不要太早得到太多的细节。如果你不能适应在一个小原型上知道你所需要知道的，类太复杂（要么你太细了，要么你应该创建多个类）。理想的类应该一目了然。 CRC原型的想法是帮助你实现设计的第一个剪辑，以便您可以获得大图，然后完善设计。

CRC原型的一大优点在于通信。最好在一组中实时完成，不用电脑。每个人负责几个类（起初没有名字或其他信息）。你一次通过解决一个场景来运行实时模拟，决定哪些消息发送到各种对象以满足每个场景。当你经历这个过程，你会发现你需要的类与他们的职责和协作，你填写这些原型。当你浏览所有用例后，你应该先设计一个相当完整的设计。

在开始使用CRC原型之前，最初设计的最成功的咨询体验涉及站在前面没有建立过OOP项目的团队面前，并在白板上绘制对象。我们讨论了对象应该如何进行通信，并删除其中的一些，并用其他对象替换它们。实际上，我正在管理白板上的所有“CRC原型”。团队（谁知道项目应该怎么做）实际上创造了设计;他们“拥有”设计，而不是给予它。

我正在做的是通过提出正确的问题，尝试假设，并采取团队的反馈来修改这些假设来指导这个过程。这个过程的转折之处在于，团队学习了如何做面向对象的设计，不是通过回顾抽象的例子，而是通过研究当时最有趣的一个设计：他们的设计。

一旦你想出了一套CRC原型，你可能想使用UML来创建一个更正式的设计描述。你不需要使用UML，但它可以是有用的，特别是如果你想在墙上放置一个图表，让大家思考，这是一个好主意。 UML的替代方法是对象及其接口的文本描述，或者根据编程语言，代码本身。

UML还提供了一个附加的图表符号来描述系统的动态模型。这有助于在系统或子系统的状态转换中足够占优，为此他们需要自己的图表（例如在控制系统中）。对于其中数据是主要因素（如数据库）的系统或子系统，你可能还需要描述数据结构。

当你描述对象及其界面时，你将了解完成阶段2。

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[25462]，资料为PDF文档或Word文档，PDF文档可免费转换为Word