第二部分 项目分析设计

第2章 项目开发流程与分析设计概述

作者希望通过这本书推广一种最有效的学习与培训方法：Project-driven training，也就是用项目实战来带动理论的学习。这里先介绍一些项目开发的背景知识。

2.1 项目开发流程RUP

RUP（Rational Unified Process）是目前最流行的一套项目开发流程模式，其基本特征是通过多次迭代完成一个项目的开发，每次迭代会带来项目整体的递增。如图2-1所示。

纵向来看，项目的生命周期或工作流程包括：项目需求分析、系统分析和设计、实现、测试和维护。横向来看，项目开发分为4个阶段：起始（Inception）、细化（Elaboration）、建造（Construction）和移交（Transition），每个阶段都包括一次或多次迭代。在每次迭代中，可以根据不同的要求或工作流（如需求、分析和设计等）投入不同的工作量，也就是说，在不同阶段的每次迭代中，生命周期的每个步骤是同步进行的，但权重不同。这是与传统瀑布式开发流程最大的区别。

项目生命周期具体如下。

1.项目需求分析

需求分析阶段包括定义潜在的角色（角色指使用系统的人和与系统互相作用的软、硬件环境）、识别问题域中的对象和关系、基于需求规范说明、角色的需要发现用例（use case）和详细描述用例。

2.系统分析和设计

系统分析阶段是基于问题和用户需求的描述，建立现实世界的计算机实现模型。系统设计是结合问题域的知识和目标系统的体系结构（求解域），将目标系统分解为子系统，之后基于分析模型，添加细节，完成系统设计。

3.实现

又称编码或开发阶段，也就是将设计转换为特定的编程语言或硬件，同时保持先进性、灵活性和可扩展性。在这个阶段，设计阶段的类被转换为使用面向对象编程语言编制（不推荐使用过程语言）的实际代码。这一任务可能比较困难，也可能比较容易，主要取决于所使用的编程语言本身的能力。

4.测试和维护

测试是检验系统是否满足用户功能需求以便增加用户对系统的信心。系统经过测试后整个开发流程便进入运行维护或新的功能扩展时期。

项目开发的4个阶段具体如下。

1.起始阶段（The Inception Phase）

对于新的开发项目来说，起始阶段是很重要的，在项目继续进行前，我们必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项目的实施价值及可行性。

起始阶段有4个重要活动，分别为：

制定项目的范围

计划并准备业务案例

综合得出备选构架

准备项目环境

2.细化阶段（The Elaboration Phase）

细化阶段的目标是为系统构架设立基线（baseline），为在构建阶段开展的大量设计与实施工作打下坚实的基础。构架是通过考虑最重要的需求与评估风险演进而来的。构架的稳定性是通过一个或多个构架原型（prototype）进行评估的。

3.构建阶段（The Construction Phase）

构建的目标是完成系统开发。构建阶段从某种意义上来说，可以看作是一个制造过程，其重点工作就是管理资源、控制操作以优化成本、日程和质量。从这个意义上来讲，管理理念应该进行一个转换，从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。

构建阶段的每次迭代都具有三个关键活动：

管理资源与控制过程

开发与测试组件

对迭代进行评估

4.交付阶段（Transition Phase）

交付阶段的焦点是确保软件对于最终用户是可用的。交付阶段包括为发布应用而进行产品的测试、在用户反馈的基础上做微小的调整等几方面内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。

交付阶段的关键活动如下：

确定最终用户支持资料

在用户的环境中测试可交付的产品

基于用户反馈精确调整产品

向最终用户交付最终产品

2.2 UML概述

UML（Unified Modeling Language）是实现项目开发流程的一个重要工具，它是一套可视化建模语言，由各种图来表达。图就是用来显示各种模型元素符号的实际图形，这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。一般来说，一个系统模型拥有多个不同类型的图，一个图是某个特定视图的一部分。通常，图是被分配给视图来绘制的。另外，根据图中显示的内容，某些图可以是多个不同视图的组成部分。

图具体分为静态模型和动态模型两大类。其中，静态模型包括：

用例图（Use-case Diagram）

类图（Class Diagram）

对象图（Object Diagram）

组件图（Component Diagram）

部署图Deployment diagrams

动态模型包括：

序列图（Sequence Diagram）

协作图（Collaboration Diagram）

状态图（State chart Diagram）

行为图（Activity Diagram）

其中三种最常用的图为：用例图，类图和序列图。

2.2.1 用例图

用例图（Use-case Diagram）显示多个外部参与者及他们与系统之间的交互和连接，如图2-2所示。一个用例是对系统提供的某个功能（该系统的一个特定用法）的描述。虽然实际的用例通常用普通文本来描述，但是也可以利用一个活动图来描述用例。用例仅仅描述系统参与者从外部观察系统得到的那些功能，并不描述这些功能在系统内部是如何实现的，也就是说，用例定义系统的功能需求。

2.2.2 类图

类图（Class Diagram）用来显示系统中各个类的静态结构，如图2-3所示。类代表系统内处理的事物，这些类可以以多种方式相互连接在一起，包括：关联（类互相连接）、依赖（一个类依赖/使用另一个类）、特殊化（一个类是另一个类的特化）或者打包（多个类组合为一个单元）。所有的这些关系连同每个类的内部结构都在类图中显示。其中，一个类的内部结构是用该类的属性和操作表示的。由于类图所描述的结构在系统生命周期的任何一处都是有效的，所以通常认为类图是静态的。

我们常常会使用特殊化（Specialize）、一般化（Generalize）、特化（Specialization）和泛化（Generalization）这几个术语来描述两个类之间的关系。例如，对于一个类A（即父类）派生出另一个类B（即子类）这样一个过程，也常常这样描述：类A可以特殊化为类B，而类B可以一般化为类A；或者类A是类B的泛化，而类B是类A的特化。

一个系统一般都有多个类图，（并不是所有的类都放在一个类图中），并且一个类可以参与到多个类图中。

2.2.3 对象图

对象图（Object Diagram）是类图的一个变体，它使用的符号与类图几乎一样。对象图和类图之间的区别是：对象图用于显示类的多个对象实例，而不是实际的类。所以，对象图就是类图的一个实例，显示系统执行时的一个可能的快照——在某一时间点上系统可能呈现的样子。虽然对象图使用与类图相同的符号，但是有两处例外：用带下画线的对象名称来表示对象和显示一个关系中的所有实例，如图2-4所示。

虽然对象图没有类图那么重要，但是它们可以用于为一个复杂类图提供示例，以显示实际和关系可能的样子。另外，对象图也作为协作图的一部分被使用，其作用是显示一群对象之间的动态协作关系。

2.2.4 状态图

一般来说，状态图（State Diagram）是对类的描述的补充。它用于显示类的对象可能具备的所有状态，以及那些引起状态改变的事件，如图2-5所示。对象的一个事件可以是另一个对象向其发送的消息，例如到了某个指定的时刻，或者已经满足了某条件。状态的变化称之为转换（Transition）。一个转换也可以有一个与之相连的动作，后者用以指定完成该状态转换应该执行的操作。

在实际建模时，并不需要为所有的类都绘制状态图，仅对那些具有多个明确状态的类，并且类的这些不同状态会影响和改变类的行为时才绘制类的状态图。另外，也可以为系统绘制整体状态图。

2.2.5 顺序图

顺序图（Sequence Diagram）显示多个对象之间的动态协作，如图2-6所示。顺序图重点是显示对象之间发送的消息的时间顺序，也显示对象之间的交互，也就是在系统执行时，某个指定时间点将发生的事情。顺序图由多个用垂直线显示的对象组成，图中时间从上到下推移，并且顺序图显示对象之间随着时间的推移而交换的消息或函数。消息是用带消息箭头的直线表示的，并且位于垂直对象线之间。时间说明及其他注释放到一个脚本中，并将其放置在顺序图的页边空白处。

2.2.6 协作图

协作图（Collaboration Diagram）像顺序图一样显示动态协作。为了显示一个协作，通常需要在顺序图和协作图之间作出选择。除了显示消息的交换（称之为交互）外，协作图也显示对象及它们之间的关系（上下文）。通常，选择顺序图还是协作图的决定条件是：如果时间或顺序是需要重点强调的方面，那么选择顺序图；如果上下文是需要重点强调的方面，那么选择协作图。顺序图和协作图都用于显示对象之间的交互。

协作图当做一个对象图来绘制，它显示多个对象及它们之间的关系（利用类/对象图中的符号来绘制）。协作图中对象之间绘制的箭头显示对象之间的消息流向。图中的消息上放置标签，用于显示消息发送的顺序。协作图也可以显示条件、迭代和返回值等信息。当开发人员熟悉消息标签语法之后，就可以读懂对象之间的协作及跟踪执行流程和消息交换顺序。除此之外，协作图也可以包括活动对象，这些活动对象可以与其他活动对象并发执行，如图2-7所示。

2.2.7 活动图

活动图（Activity Diagram）用于显示一系列顺序的活动，如图2-8所示。尽管活动图也可以用于描述像用例或交互这类的活动流程，但是一般来说，它主要还是用于描述在一个操作内执行的那些活动。活动图由多个动作状态组成，后者包含将被执行的活动（即一个动作）的规格说明。当动作完成后，动作状态将会改变，转换为一个新的状态（在状态图内，状态在进行转换之前需要标明显式的事件）。于是，控制就在这些互相连接的动作状态之间流动。同时，在活动图中也可以显示决策和条件，以及动作状态的并发执行。另外，活动图也可以包含那些被发送或接收的消息的规格说明，这些消息是被执行动作的一部分。

2.2.8 组件图

组件图（Component Diagram）是用代码组件来显示代码物理结构的。其中，组件可以是源代码组件、二进制组件或一个可执行的组件。由于一个组件包含它所实现的一个或多个逻辑类的相关信息，于是就创建了一个从逻辑视图到组件视图的映射。根据组件图中显示的组件之间的依赖关系，可以很容易地分析出其中某个组件的变化将会对其他组件产生的影响。另外，组件也可以用它们输出的任意接口来表示，并且可以被聚集在包内。一般来说，组件图用于实际的编程工作中，如图2-9所示。

2.2.9 部署图

部署图（Deployment Diagram）用于显示系统中的硬件和软件的物理结构。它可以显示实际的计算机和设备（节点），同时还有它们之间的必要连接，也可以显示这些连接的类型。在图中显示的节点内，已经分配了可执行的组件和对象，以显示这些软件单元分别在哪个节点上运行。另外，部署图也可以显示组件之间的依赖关系。

正如前面所说的那样，显示部署视图的部署图描述系统的实际物理结构，这与用例视图的功能描述完全不同。但是，对一个明确定义的模型来说，可以实现从头到尾的完整导航：从物理结构中的一个节点导航到分配给该节点的组件，再到该组件实现的类，接着到该类的对象参与的交互，最终到达用例。系统的不同视图在总体上给系统一个一致的描述，如图2-10所示。

2.3 小结

图2-10 系统物理结构的部署图

本章讲解了项目开发的背景知识。首先介绍了项目开发流程RUP（Rational Unified Process），使读者对RUP有了基本的了解，然后讨论了UML（Unified Modeling Language），它是实现项目开发流程的一个重要工具，是一套可视化建模语言，由各种图来表达。