1.9.2　第1阶段：我们在做什么

在上一代程序设计[称为过程型设计（procedural design）]中，这一阶段称为“建立需求分析（requirements analysis）和系统规范说明（system specification）”。这些当然是容易迷路的地方。它们是一些名字很吓人的文档，本身可能就是大项目。当然，它们的目的是好的。需求分析说的是“制定一系列指导方针，我们将利用它了解任务什么时候完成且用户什么时候满足”。系统规范说明指出，“这是程序将做什么（不是如何做）以满足需求的一个描述”。需求分析实际上是我们和用户之间的一个合同（即使用户在我们的公司工作或是另一些对象或系统）。系统规范说明是对问题的一个顶层探测，且在一定程度上要说明项目是否能做和将需多少时间。由于这两个问题需要人们的共识（并且因为他们通常会随时间的推移而改变意见），我认为最好将它们尽可能地保持最小限度（理想情况下，是列表和基本的图表）以节省时间。我们可能有其他的限制，如需要将它们扩展为大一些的文档，但是小而简洁的最初文档，可以在由一个动态创建描述的领导者的带领下，通过很少几次头脑风暴（brainstorming）讨论而得到。这不仅需要每个人的投入，而且能激励小组中每个成员参与，使他们意见一致。也许，最重要的是，它可以使项目以极大的热情开始。

这一阶段中我们有必要把注意力始终放在核心问题上：确定这个系统要做什么。为此，最有价值的工具是一组所谓的“用例（use case）”。用例指明了系统中的关键特性，它们将展现我们使用的一些基本的类。它们实际上是对类似下述这些问题的描述性回答^[1]：

1）“谁将使用这个系统？”

2）“执行者用这个系统做什么？”

3）“执行者如何用这个系统工作？”

4）“如果其他人也做这件事，或者同一个执行者有不同的目标，该怎么办？（揭示变化）”

5）“当使用这个系统时，会发生什么问题？（揭示异常）”

例如，如果设计一个自动取款机，此系统的一个特定功能方面的用例能够描述这台自动取款机在任何可能情况下的行为。这些“情况”每一个称为情节（scenario），而用例可以认为是情节的集合。我们可以把情节认为是以“如果……系统将怎样？”开头的问题。例如，“如果一个用户在24小时内刚刚存了一张支票，且在此支票之外该账户中没有足够的钱能满足提款要求，这时自动取款机怎么办？”。

下面的用例图特意进行了简化，以防止我们过早地陷入到系统的实现细节问题中去。

每个小人代表一个“执行者（actor）”，它通常是一个人或其他类型的自由代理（甚至可以是其他计算机系统，如“ATM”中的情况）。方框代表系统的边界。椭圆代表用例，是对此系统能完成的有价值工作的描述。在执行者和用例之间的直线代表交互。

只要符合用户的使用感受，系统实际上如何实现并不重要。

用例不必十分复杂，即便底层系统非常复杂。这只是为了表示用户眼中的系统形象。例如：

通过确定用户在系统中可能有的所有交互行为，用例就生成了需求规范说明。我们试图找到系统的完整用例，完成之后，我们就得到了系统任务的核心内容。注意力集中在用例上的好处是，它们总是将我们带回到要点部分而不至于留心那些对完成任务无关紧要的问题。也就是说，如果得到了全部用例就可以描述系统并进入到下一个阶段。在最初的尝试中我们很难完全得到特征，但这已经很好了。任何事物随着时间的推移都会自己暴露出来，如果在这一点上就要求系统规范说明完美将会永远止步不前。

如果遇到了困难，我们可以通过使用一个近似工具启动这个阶段：用很少的段落描述此系统，然后寻找名词和动词。名词往往意味着执行者、用例的上下文（如“休息室”）或在用例中使用的物品。动词往往意味着执行者和用例之间的交互行为，表示用例中的特定步骤。我们还将发现名词和动词在设计阶段将对应产生对象和消息（注意用例描述子系统间的交互，因此“名词和动词”技术只能作为集体讨论工具，因为它不生成用例）。^[2]

用例和执行者之间的边界能指出用户界面的存在，但不能定义这样的用户界面。为了定义和创建用户界面，可参看Larry Constantine和Lucy Lockwood所著的《Software for Use》（Addison Wesley Longman，1999）或访问www.ForUse.com。

虽然这有点像魔术，但此时进行某种基本的进度安排是重要的。我们现在有了创建目标的总体概念，所以我们可能产生它需要多长时间的概念。这里涉及大量因素。如果估算了一个长时间表，则公司可能决定不创建它（并把资源用在更合理的项目上去，这是好事）。或者管理人员可能已经决定这个项目应当花多少时间，并且试图改变我们做出的估计。但是最好一开始有一个准确的时间表，解决早期决心的问题。已经有大量的努力以产生精确建立时间表的技术（就像预测股票市场的技术），然而，最好的方法或许是依靠我们的经验和直觉。得到实际上将花多少时间的估计，加倍，再加上百分之十。我们的直觉也许是对的，我们能及时得到能用的产品。“加倍”将使产品更好，加百分之十用于最后的润色和细化^[3]。然而，我们需要解释它，克服抱怨和当我们拿出这个时间表时发生种种事情，最终完成这一问题。

[1]感谢James H Jarrett的帮助。

[2]更多有关用例的内容可以在Schneider＆W inters所写的专著《Applying Use Cases》（Addison-Wesley，1998）和Rosenberg所写的专著《Use Case Driven Object Modeling with UML》（Addison-Wesley，1999）中找到。

[3]我个人观点后来已经变了。加倍和增加百分之十将给出相当准确的估计（假设这里没有太多的不定要素），但是我们仍然需要勤奋工作，以及时完成。如果我们希望时间真的花这么长，并且在这个过程中得到乐趣，我认为，正确的增加是3到4倍。