3.1 分析设计过程简介

为了能够有效地进行软件系统的分析和设计，需要将各个技术层次合理地、适时地结合在一起，这就需要遵循一定的过程，也就是软件工程过程所要求的内容。虽然UML提供了有效地表达分析和设计思想的手段，但是如何合理地、适时地利用这些手段去进行分析和设计是UML所不能提供的。因此，从本质上来讲，UML仅仅是一种标准的表达形式，它提供了统一的符号体系，使人们摆脱了符号之间的困扰，从而可以专心面对业务问题。而用好UML除了需要掌握面向对象分析和设计的基本原则和方法外，还需要借助一定的软件开发过程。

与UML配套的软件工程过程很多，其中应用最广的还是与UML同出一门的Rational统一过程（Rational Unified Process, RUP）。Rational统一过程是一个庞大的、应用于企业应用开发的工程过程，它提供了如何在开发组织中严格分配任务和职责的方法，其目标是按照预先制定的时间计划和经费预算，开发高质量的软件产品以满足用户的需求，其核心思想是用例驱动、以架构为中心的迭代增量开发。本书并不是一本介绍过程的书，但是为了能够有效地进行分析和设计，还必须采纳一定的过程，而RUP过程本身过于复杂，并不符合本书的学习要求。因此本书在借鉴RUP思想的基础上，定义了重点关注分析和设计的简化过程，这样既保证能够按照有效的过程进行分析和设计，又不会因为过于复杂的过程而影响到对分析和设计方法的学习。

3.1.1 UML分析设计过程解析

本书所讨论的UML分析设计过程起始于业务建模，接下来是需求建模、用例分析、架构设计和构件设计，最后终止于代码实现。本书的后续内容将按照这个过程展开。当然，这个过程并不是完整的软件开发过程（如缺少计划、管理、测试、维护等方面的内容），这里重点关注的是分析和设计。此外，书中对于这些阶段的描述是线性的，但在实际应用过程中它应该是一个迭代增量的过程。这个过程如图3-1所示，框内的图示是相关阶段所要使用的主要的UML图例。

图3-1 UML分析设计过程

（1）业务建模：采用软件建模方法分析和理解待开发的业务，描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础。此部分内容对应本书第3章。

（2）用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入。此部分内容对应本书第4章。

（3）用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型。此部分内容对应本书第5章。

（4）架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构。此部分内容对应本书第8章（第6章和第7章是设计的基础理论）。

（5）构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节。此部分内容对应本书第9章。

（6）代码实现：将系统构件映射到目标语言上。此部分内容对应本书第10章。

3.1.2 结合过程应用UML

UML和过程本身并不存在严格的对应关系，它们之间是一种多对多的关系；不同的过程、不同的阶段对UML使用有不同的要求。如RUP方法中提供了4个阶段9个工作流的二维过程模式，但是在某个特定的阶段、对于特定的工作流采用何种UML模型进行建模，这些在RUP中并没有做强制的规定。不过RUP却提供了很多最佳实践，这些最佳实践提醒用户只有合理地利用UML，才能发挥RUP方法的特点。

关于UML和过程的关系可以采用一个形象的比喻：过程是一种“战术”，它决定了项目团队如何去合理地安排资源、进度或人员；而UML则是一种“作战技能”，是团队成员的使能技术，再好的战术缺少合适的人去执行也是空谈。这两者之间是相辅相成的。

本书在定义UML分析设计过程时，给读者提供了一些可参考的最佳实践。正如图3-1所示，每个阶段都有不同的UML模型去支撑。在业务阶段，采用扩展的业务用例模型进行业务建模，采用活动模型进行业务流程的细化。在用例建模阶段，采用用例模型进行需求建模，采用用例文档来详述需求。在用例分析阶段，采用扩展的类模型表示静态关系，采用交互模型表示动态交互。在设计阶段则采用包、构件、部署等模型表示软件架构，采用静态类图、动态交互图、状态模型来进行详细的类设计。在代码实现阶段，则根据设计类图、设计交互图生成代码。这些模型的细节和使用方式将在本书的后续章节中详细展开讨论。

图3-1给出的是一个相对完整的在系统开发过程中使用UML的示意图。在项目实践过程中，团队可以根据自身的实际情况逐步引入不同的UML模型。早期，可以只在需求阶段采用用例建模技术，后续过程仍沿用以前传统的方式进行分析和设计。在此基础上，下一步可以利用UML类图进行静态分析和设计。最后，可以更进一步使用UML交互模型进行动态分析和设计，从而使用UML模型覆盖项目的全生命周期。