第5章 餐系统：分析.doc

第5章 餐馆系统：分析 分析经常看作是软件开发中的一个不同阶段或活动，但是，分析和设计的区分并不总是非常清晰的。在面向对象方法中尤其如此：因为开发从头到尾都使用相同的概念和表示法，分析和设计经常像是互相融合在一起。本章介绍的分析的观点来自于统一过程，但是应该指出，不同的作者和方法学会给出不同的解释，而且在有些情况下甚至认为分析不是一个独立的活动。 5.1 分析的目的 定义分析目的的一种方法是确定分析的是什么。在完整的开发语境中，对这个问题的一个看来合理的答案是“系统需求”。以用例描述的形式陈述的需求是定义系统外部行为非常有价值的工具，但是它们对系统的内部结构，或如何提出一组交互的对象来支持所要求的功能并没有给出任何指导。因此，可以把分析的任务描述为是构造一个模型，来说明这些交互的对象如何能够交付用例中规定的行为。 用工作产品的词语来说，分析活动的典型输入是用例和领域模型。虽然这些模型描述了系统的结构和行为方面，但是这些描述不是非常完整的。用例描述通过用户与系统的交互来表示从外部看到的系统功能，而领域模型则定义了重要业务概念之间的关系。缺少的是对如何表示或者导出源于业务实体的这些对象，以怎样的方式协作才能实现用例中规定的行为的阐述。 分析工作流借助于一种称为实化（realization）的技术处理这个问题。在实化过程中，对每个用例，应当开发一个高层交互，来说明如何通过适当类的实例的交互，产生所需要的系统行为。 根据面向对象系统中的类常常能够由现实世界的实体得出的指导原则，通常，领域模型中的类构成用例实化的起点。但是，进行实化的过程总是导致领域模型的变更，在本章中到处都可以看到这样的例子。除了实化之外，分析工作流还产生一个分析模型（analysis model），这是源于领域模型的一个类图，但并入了为使其能够支持用例中规定的功能而增加和修改的内容。 在UML中用交互图（interaction diagram）定义用例的实化，交互图共有两种。协作图（collaboration diagram）在第2章中说明库存控制程序的行为时已经非正式地使用过。另一种交互图是顺序图（sequence diagram），用于文档化本章中用例的实化。这两种形式的图差不多是等价的，提供了表示相同信息的不同方式。顺序图清晰地说明了各种事件的发生次序，因而在交互的各种事件的发生次序特别重要时常常使用。 统一过程还把系统架构描述（architectural description）的产生包括在分析工作流中。这是关于系统总体结构的一些相当高层的决策的文档，而不是如何处理各个用例的局部细节。架构描述将在5.3节更详细地叙述。 分析和设计的区别 分析最重要的任务是产生用例实化，并以此为基础，使领域模型进化为一个更全面的类图。无论是否定义了单独的分析活动，这些活动都是面向对象开发的基础。 原则上，用例实化可以进行得如此详细，致使从每个用例实化都可以看出最终代码中的每个交互和方法调用，并且使类模型也将展示几乎和类实现同样多的信息。由于分析和设计自始至终可以使用相同的技术和表示法，因此要给出一个清晰的界线作为分析结束而设计开始的形式定义就非常困难。这种看法成为决定将分析和设计作为一个单个活动，或者完全没有明显的分析阶段的基础。 如果要区别分析和设计，只能是非形式的，基于采取的不同观点，而不是任何技术的差异。例如，分析的重点集中在系统需求上，而在设计中重点转移到了要产生的软件的结构上。分析用对象模型表示应用领域，而在设计中我们将把为设计做准备的分析模型转化为一个具体的软件产品。 5.2 对象设计 为了产生实化一个用例的交互图，必须在一组对象之间分配所需要的数据和处理，那么这些对象就可以进行交互以支持用例规定的功能。通常这是开发面向对象系统最困难和最具创造性的方面，因为经常有许多不同的可能设计结果可以使用，而且哪个是最佳选择往往并不明显。 领域模型定义了一组具有属性和关系的类，用这些作为设计的基础是很吸引人的想法。虽然在相当大的程度上常常是这样，但是需要记住的是领域模型有许多局限性。 首先，领域模型表示了应用领域中的重要概念。在最终的设计中对这些概念和它们的关系应该有一个相当直接的表示，这当然是面向对象设计的一个愿望，但是并不能保证情况总是这样。至少，最后的设计总会包含一些类，这些类或者在领域模型中虽然没有出现却是在进一步的设计工作过程中被发现的，或者是在应用领域中没有相似物的类。 其次，领域模型通常不显示操作。然而，开发设计时至关紧要的一部分就是决定每个对象应该完成什么处理，然而领域模型对此没有提供任何帮助。现实世界中的行动和对象模型中的操作不同，所以即使在领域模型中增加行动，也不太可能在分析中提供多少帮助。 本节讨论对象设计的基本原