第2章 IT项目开发流程与UML概述

2.1 项目开发流程

项目开发并不是一个简单的过程，我们需要遵循一些开发流程。一个项目的开发会被分成很多步骤来实现，每一个步骤都有自己的起点和终点。也正如此，使得开发过程中每个步骤的起点和终点在不同的软件项目中会出现不同难度的“坎”，使其难于达到该步骤开始或终结的条件，开发过程也就不会一帆风顺。

不同的开发模式其实就是将步骤的起点和终点重新定义，甚至重新组合排列。虽然任何一个开发模式的最终目的都是完成软件项目的开发，但期间所经历的过程不一样，过程步骤之间的起点和终点的定义不同，所带来的“坎”也就不一样，项目周期自然各不相同。因此，根据软件项目的实际情况，选择一种适合的开发模式能减少开发周期中“坎”的出现次数与难度，可以很大程度地缩短开发周期。

我们首先了解一下传统瀑布式（Waterfall）开发流程，如图2-1所示。

瀑布模型是由W.W.Royce在1970年首先提出的软件开发模型。在瀑布模型中，开发被认为是按照需求分析、设计、实现、测试（确认）、集成和维护这一顺序坚定而顺畅地进行的。线性模型太理想化、太单纯，以至于很多人认为瀑布模型已不再适合现代的软件开发模式，几乎被业界抛弃。

这里向大家推荐的是统一开发流程RUP（Rational Unified Process），它是目前最流行的一种项目开发流程模式，其基本特征是通过多次迭代完成一个项目的开发，每次迭代都会带来项目整体的递增，如图2-2所示。

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

2.1.1 项目生命周期

1.需求分析

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

2.系统分析和设计

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

3.实现

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

4.测试和维护

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

2.1.2 项目开发阶段

1.起始阶段（Inception Phase）

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

起始阶段有以下4个重要活动。

● 制定项目的范围。

● 计划并准备业务案例。

● 综合分析，得出备选构架。

● 准备项目环境。

2.细化阶段（Elaboration Phase）

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

3.构建阶段（Construction Phase）

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

构建阶段的每次迭代都具有以下3个关键活动。

● 管理资源与控制过程。

● 开发与测试组件。

● 对迭代进行评估。

4.交付阶段（Transition Phase）

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

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

● 确定最终用户支持资料。

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

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

● 向最终用户交付最终产品。

最后，作为补充，再简单介绍一种新的开发流程：敏捷开发和极限编程。

2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭的问题，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法有很多，主要有SCRUM、Crystal、特征驱动软件开发（Feature Driven Development，FDD）、自适应软件开发（Adaptive Software Development，ASD），以及最重要的极限编程（eXtreme Programming，XP）。

极限编程是一套快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上的软件工程不同，同时，它也和传统的管理和项目计划的方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。

XP具有12个过程，只有完全使用12个过程才是真正使用了XP，只是简单地使用了其中的一个过程并不代表使用了XP。XP的12个过程如下：

● 现场客户（On-site Customer）

● 计划博弈（Planning Game）

● 系统隐喻（System Design）

● 简化设计（Simple Design）

● 集体拥有代码（Collective Code Ownership）

● 结对编程（Pair Programming）

● 测试驱动（Test-driver）

● 小型发布（Small Release）

● 重构（Refactoring）

● 持续集成（Continous Integration）

● 每周40小时工作制（40-hour Weeks）

● 代码规范（Coding Standards）

下面是极限编程的有效实践。

● 完整团队XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表，以及其他一些显示进度的东西。

● 计划博弈是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

● 客户测试作为选择每个所期望特性的一部分，客户可以根据脚本语言定义出自动验收测试以表明该特性可以工作。

● 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

● 结对编程：所有的产品软件都是由两个程序员并排坐在一起在同一台机器上构建的。

● 测试驱动开发：编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

● 改进设计随时利用重构方法改进已经腐化的代码，使代码尽可能地干净，具有表达力。

● 持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其他所有人负责代码集成。

● 集体拥有代码：任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其他方面的开发。

● 编码标准系统中所有的代码看起来就好像是由一人单独编写的。

● 系统隐喻：将整个系统联系在一起的全局视图，它是系统的未来影像，使所有单独模块的位置和外观变得明显、直观。如果模块的外观与整个隐喻不符，那么就会知道该模块是错误的。

● 可持续的速度团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，保存精力，把项目看做是马拉松长跑，而不是全速短跑。

极限编程是一组简单、具体的实践，这些实践结合在一起形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

2.2 UML概述

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

2.2.1 UML图

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

● 用例图（Use Case Diagram）

● 类图（Class Diagram）

● 对象图（Object Diagram）

● 组件图（Component Diagram）

● 部署图（Deployment Diagram）

动态模型包括：

● 序列图（Sequence Diagram）

● 协作图（Collaboration Diagram）

● 状态图（State Diagram）

● 活动图（Activity Diagram）

具体见表2-1。

1.用例图

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

2.类图

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

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

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

3.对象图

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

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

4.组件图

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

5.部署图

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

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

6.序列图

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

7.协作图

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

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

8.状态图

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

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

9.活动图

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

2.2.2 UML建模工具及使用

1.Rational Rose工具简介

在使用UML进行面向对象分析设计工作中，我们常常使用一些工具。Rational Rose就是这样一种UML建模工具，它可以提供建立、修改和操作Rose视图的功能。Rose运行环境为Windows NT、Windows 95、UNIX（Solaris、HP/UX、AIX、DEC Unix），Rose支持Unified、Booch、OMT标记法。

在Rose中有4种视图，分别是Use Case视图、逻辑视图、组件视图和拓扑视图。

（1）Use Case视图

Use Case视图中包含以下图形：

① Use Case图：包、actors、Use Case和关系。

② 交互图（序列图或协同图）：对象和消息。

Use Case图描述了存在的actors（外部系统）、Use Case（该系统应该执行什么）及它们的关系。Use Case图可以描述该系统中部分或全部的Use Case。交互图描述了系统在逻辑设计中存在的对象及其间的关系，它可以代表系统中对象的结构。Rose中包含两种交互图，它们对同一交互操作提供了不同的浏览视角。

● 序列图：按时间顺序排列对象的交互操作。

● 协作图：围绕对象及其间的连接关系组织对象的交互操作。

（2）逻辑视图

逻辑视图中的元素可以用一种或多种图形来表示。逻辑视图中可以包含以下图形：

① 类图：包、类和类的关系。

② 状态图：状态、事件和转换关系。

类图是描述系统的静态视图，它描述了系统逻辑设计中存在的包、类及它们的关系。类图可以代表该系统中部分或全部的类结构，在模型中有一些典型的类图。

状态图描述了给定类的状态转换空间；导致状态转换的事件；导致状态改变的动作。

（3）组件视图

组件视图中的元素可以在一个或多个组件图中被浏览。

组件图描述了在系统物理设计中组件中类和对象的分配情况，组件图可以代表系统中部分或全部的组件结构。组件图描述了包、组件、依赖关系。

（4）拓扑视图

拓扑视图中的元素可以在拓扑图形中被浏览，拓扑视图只能包含一个拓扑图形。拓扑视图描述了一个系统在物理设计阶段进程处理的分配情况。

2.Rational Rose的使用

（1）用例图

① 右键单击“Use Case View”，选择“New→Use Case Diagram”，新建用例图视窗，如图2-12所示。

② 单击工具栏中的“Use Case”工具，在视窗中单击便可添加用例；也可以右键单击“Use Case View”，选择“New→Use Case”添加用例，然后按住左键将添加的用例拖入视窗中使用（见图2-13）。

③ 双击用例或者右键单击用例，选择“Open Specification...”（见图2-14），在弹出的对话框中设置用例属性，如图2-15所示。

④ 单击工具栏上的“Actor”工具，在视窗中单击便可添加角色；也可以右键单击“Use Case View”，选择“New→Actor”添加角色，然后按住左键将添加的角色拖入视窗中使用（见图2-16）。

⑤ 双击角色或右键单击角色，选择“Open Specification...”（见图2-17），在弹出的对话框中设置角色属性，如图2-18所示。

⑥ 使用工具栏上的“Unidirectional Association”工具添加角色与用例之间的关联。单击“Unidirectional Association”选择角色，按住左键拖向该角色应有的用例。

完整的用例图实例如图2-19所示。

（2）类图

① 右键单击“Use Case View”，选择“New→Class Diagram”新建类图视窗，如图2-20所示。

② 单击工具栏上的“Class”工具，在视窗中单击便可添加类；也可以右键单击“Use Case View”，选择“New→Class”添加类，然后按住左键将添加的类拖入视窗中使用，如图2-21所示。

③ 双击类或右键单击类，选择“Open Specification...”（见图2-22），在弹出的对话框中为该类添加方法和属性，如图2-23所示。

④ 单击工具栏上的“Interface”工具添加接口。

⑤ 双击接口或右键单击接口，选择“Open Specification...”（见图2-24），在弹出的对话框中为该接口添加方法，如图2-25所示。

⑥ 添加类的继承关系和接口的实现（见图2-26）。用“Generalization”工具描述类的继承，用“Realize”工具描述接口的实现，用“Dependency or instantiates”工具描述依赖。

完整的类图实例如图2-27所示。

（3）序列图

① 右键单击“Use Case View”，选择“New→Sequence Diagram”新建序列图视窗，如图2-28所示。

② 单击工具栏上的“Object”工具添加对象，双击选择对应类或接口；也可以按住左键把已经生成的类和接口拖入序列图视窗中使用，如图2-29所示。

③ 用工具栏中的“Object Message”工具表示执行顺序，用工具栏中的“Return Message”工具表示返回，如图2-30所示。

④ 双击Object Message和Return Message添加说明，如图2-31和图2-32所示。

完整的序列图实例如图2-33所示。

另外一个常用建模工具是Microsoft Visio，接下来我们介绍Visio的使用方法。

3.Microsoft Visio工具简介

Microsoft Office Visio提供的模板、形状和绘图工具可用于创建有效的业务图表和技术图表。使用Visio Standard，可以分析业务流程、安排项目日程、形象地表达思维过程以及绘制组织结构图。使用Visio Professional，除了可以完成上述任务外，还可以形象地显示网络基础设施、平面布置图、公共设施设备、电路、软件系统和数据库结构。

在熟悉的Microsoft环境中工作时，您还可以通过导入数据来创建图表、从图表中导出数据、使用图表存储数据、根据存储的数据生成报告以及将图表并入Microsoft Office文件。

Microsoft Visio有助于IT和商务专业人员轻松地查看、分析和交流复杂的信息。它能够将难以理解的复杂文本和表格转换为一目了然的Visio图表。该软件通过创建与数据相关的Visio图表来显示数据，这些图表易于刷新，并能够显著提高生产效率。使用Office Visio中的各种图表可了解、操作和共享企业内组织系统、资源和流程的有关信息。

Office Visio提供了各种模板：业务流程的流程图、网络图、工作流图、数据库模型图和软件图，这些模板可用于可视化和简化业务流程、跟踪项目和资源、绘制组织结构图、映射网络、绘制建筑地图以及优化系统。

4.Microsoft Visio的使用

（1）用例图

① 依次单击“文件→新建→软件→UML模型图”，如图2-34所示。

② 单击左侧工具栏中的“UML用例”工具，将需要添加的用例按住左键拖入视窗中使用，如图2-35所示。

③ 双击用例或右键单击用例，在弹出的快捷菜单中选择“属性”命令，在接下来弹出的对话框中设置用例属性，如图2-36和图2-37所示。

④ 单击工具栏中的“UML用例”工具，然后将要添加的角色按住左键拖入视窗中使用，如图2-38所示。

⑤ 双击角色或右键单击角色，在弹出的快捷菜单中选择“属性”命令，在接下来弹出的对话框中设置角色属性，如图2-39和图2-40所示。

⑥ 用工具栏中的“用”工具添加角色与用例之间的关联。单击“用”，接着选择角色，然后按住左键拖向该角色的应用用例，如图2-41所示。

完整的用例图实例如图2-42所示。

（2）类图

① 依次单击“文件→新建→软件→UML模型图”，如图2-43所示。

② 单击工具栏中的“类”工具，然后将添加的类按住左键拖入视窗中使用，如图2-44所示。

③ 双击类或右键单击类，在弹出的快捷菜单中选择“属性”命令，在接下来弹出的对话框中为该类添加方法和属性，如图2-45和图2-46所示。

④ 单击工具栏中的“接口”工具，然后将添加的接口按住左键拖入视窗中使用，如图2-47所示。

⑤ 双击接口或右键单击接口，在弹出的快捷菜单中选择“属性”命令，在接下来弹出的对话框中为该接口添加方法，如图2-48和图2-49所示。

⑥ 添加类的继承关系和接口的实现。用“泛化”工具描述类的继承；用“泛化”工具描述接口的实现，但需要对其进行更改；用“依赖关系”工具描述依赖。利用“泛化”工具实现接口的时候，要把线的格式改为虚线，如图2-50 和图2-51 所示。操作方法：右键单击线条，选择“格式→线条”，将图案选项改为虚线格式即可。

完整的类图实例如图2-52所示。

（3）序列图

① 依次单击“文件→新建→软件→UML模型图”，如图2-53所示。

② 单击工具栏中的“UML序列→对象生命线”工具添加对象，按住左键拖入到序列图视窗中使用，如图2-54所示。

③ 双击对象生命线，在弹出的对话框中对其属性进行更改，如图2-55所示。

④ 用工具栏中的“消息”工具表示执行顺序，用工具栏中的“消息（返回）”工具表示返回，用工具栏中的“激活”工具表示对象或方法的激活操作，效果如图2-56所示。

⑤ 双击“消息”和“消息返回”，在弹出的对话框中添加说明，如图2-57所示。

完整的序列图实例如图2-58所示。

在本书后面的内容中，我们会使用UML工具和图形来进行需求分析和系统分析设计等工作。