文章中，作者说，围绕着解决方案，各方－开发者、终端用户、消费者、执行经理等有各自的观点，为了找到一个共同的基础，我们必须提供一个需求词汇表，该词汇表可以很容易被所有各方所理解，这个词汇表是利用用例、活动图和事件流程来创建的。
书中，译者将stakeholder译为“风险承担者”，这个单词在英语中的本意是“赌金保管者”，呵呵，也不知道译者为什么要这么翻译，或许译者以为软件开发与攀登珠穆朗玛峰一样，是件冒险的事情，不仅对开发者如此，对委托者也一样；看来译者是个悲观主义者。前段事件看文章说，外界所盛传的软件开发的高失败率是个误传，真的失败率根本没有这么高。或许译者曾经沧桑，哈哈。
作者还提到，在整个过程中都要考虑重用和分解，这种思考模式可以帮助我们将共同的行为纳入用例，最终将一系列相关的用例打包到子系统中。这是很自然的事情，我以为，但真正做起来难度却不少，包括对用例的理解，包括程序员之间的协调。
UML是这样定义用例的：用例指定了一个系统或者系统中一部分的行为，它是一组动作序列（包括变体形式）的描述，系统通过执行这些动作作为参与者产生一个可观测的结果。唉，定义总是这么晦涩难懂。它接着说：从与用例交互的实体来看，用例就是这个系统的一个外部视图。它用于捕获系统的需求。用例不是原子的，一个代表复杂系统的行为的用例可以进一步分解为更多的用例。呵呵，这不就好理解多了嘛。有一句话很重要：用例需要在业务领域专家、应用体系工程师和开发人员之间创建该系统行为的一个共同理解，而不是指定这个行为如何实现。可见，用例可以表达需求，而不能代替设计。
用例归档了系统，并且构成了用户接受、集成、回归和系统测试的测试案例的基础。“归档”，感觉翻译的有问题，但看不到英文版。
理解问题域的第一步是创建一个项目描述。一个项目描述应该解释这个项目的用途。该描述必须是简洁的，而且必须迅速演示业务目标（“演示”？估计是展示Demonstrate）。项目描述是项目各方的第一个一致观点。
为了理解问题域，作者给出了一个叫GreaterCause的例子，这是一个慈善捐赠应用，但我不是很理解，或许是文化差异，或许是译者…….。
根据谁需要这个系统、他们倾向于如何使用这个系统、这个系统和谁交互作用以满足用户的需求等提供的观点，我们可以很好地理解这个系统的行为和语义。每一个围绕在系统周围并和系统交互作用的实体组成了系统的上下文，而不论它是否是一个消费者或提供者。构建系统上下文的模型有助于理解在相互连接的系统中，一个生态系统如何同其他系统交互。与这个系统通信的外部实体是一个参与者（actor）的实例，参与者不是系统的一部分。它可以是一个个体、另一个软件系统、一个异步消息或一块外部硬件。需要特别说明的是，一个参与者定义一个特殊的角色，这个角色由一个实体在系统的上下文中扮演；这就意味着一个实体可以由一个或多个参与者表示，因为实体根据系统采用的不同角色，而类似地，一个参与者代表一个或更多的实体，这个参与者在系统的上下文中扮演相同的角色。
这么理解这段话吧，所谓上下文，就是系统周围的那些东西，比如操作者，比如与本系统交互的财务软件，比如加密狗等等。书嘛，不罗嗦点咋能写那么厚呢？咋能卖那么多钱呢？哈哈。
按作者的观点，上文提到的“定义问题域”和“标识系统的上下文”就是项目描述。
标识风险因素和依赖性，在实际运用中，我们往往会忽略这个问题，作者在此处提出，我觉得跟所有的项目都相关。
将系统分解成包（这里是指用例包）有助于使系统模块化，从而使其易于理解、管理和归档。子系统级别的原子性可启用并非分析、设计以及开发不同的子系统。在需求阶段定义的包层次结构可以在分析阶段模仿系统的结构视图，每一个包可以潜在地产生一个子系统。然而在分析阶段，您仍然会发现几个和许多包交互的支持对象。例如验证模块、错误报告模块和服务定位模块可能就是几个包所共有的；因此，在分析阶段，包的结构需要修改以提供位置给这些组件。在分析阶段期间，您可能会发现需要将一个包分解成几个从属的包；确保嵌套不是多级别的，否则包将会难以管理。
小结：这一章其实与J2EE并无多大关系，作者只是重申了一些UML的概念而已。
本文地址：http://com.8s8s.com/it/it15062.htm