来源:松耦合空间制作组
在实践中，笔者发现，对概念的理解不到位，特别是对概念之间的关系理解不到位，是阻碍不少人成功应用RUP的原因之一。
本文采用“为概念及其关系建模”的方法，对概念及其关系进行考察，以期深入理解RUP的核心概念。
1、弄清概念的必要性
随着软件学科和软件业的不断发展，“名词”越来越多。但是，“名词”背后的“含义”也真的有如此之多的增长吗？
举个例子。1986年，Barry Boehm提出了软件开发的螺旋模型。从那时起，螺旋模型被当作软件开发的标准方法。螺旋模型还有其他不同的常用名字，比如演进模型，或者迭代模型[1]。类似的例子还有很多。
看来，软件界存在不少这种“新瓶装旧酒”的现象——一个新名词出现了，它可能仅仅是披着新的表达形式的外衣，而其含义其实和某个旧名词相同。
笔者认为，在软件学科飞速发展的今天，反而是踏踏实实搞清楚“变幻无穷”的诸多名词背后的真正含义，才是最便捷之道。
2、本文的方法：一图胜千言
本文采用“为概念及其关系建模”这样一种方法，不仅考察单个名词的含义，还考察名词之间的关系。
一图胜千言。一个概念的本质，往往需要从它同其他概念的关系中，得以体现。不仅考察个体，还考察多个个体之间的关系，这种方法在系统论中，被比喻成“1 + 1 > 2”。令人愉快的是硬币的另一面，注重考察关系这种方法，从其成本角度而言却是“1 + 1 < 2”。
3、RUP核心概念解析
3.1、任务来自问题
RUP著名的二维结构，其时间维相关的概念有阶段、迭代、里程碑等，内容维相关概念有工作流、角色、活动、工件等。但笔者发现，不少人对这些概念理解不深，特别是对概念之间的关系把握不到位，造成实践中出现问题。
另外，就是迭代式开发——这种包括RUP在内的多种软件工程过程都一致推崇的最佳实践——和活动、工件这些基本概念有何关系。不知道迭代和活动、工件的关系，实际应用RUP时又如何贯彻迭代式开发的思想呢？
还有，配置和变更管理对所有现代软件开发过程都是必不可少的支持活动，RUP更是将其列为“RUP的6大最佳实践”之一。但笔者发现，不少开发人员认为配置和变更管理太麻烦，仅仅是因为他们没有理解配置和变更管理和工件的基本关系。
我们的任务，就来自于这些问题。我可以用一幅图解决这些问题吗？
3.2、一图胜千言
下图是一幅UML类图，它概括了上述问题的相关概念，并着重表达了概念之间的关系。本图的丰富语义，我们通过下面几节细细来分析。
3.3、角色执行活动，活动生产工件
任何软件工程过程，都少不了角色（role）、活动（activity）、工件（artifact）等概念（或者类似概念）。
这些概念本身很好理解。角色是对个人或者作为开发团队的一组人的职责的规定；具体人和角色的关系，好比人和帽子的关系。活动就是角色执行的工作单元。工件就是工作的成品或半成品。
倒是这些概念的关系显得更加重要。角色的职责，具体体现在他执行活动和负责工件上。工件是由活动生产出来的——工件是活动的输出；比如制定《编码规范》。然而，活动本身也可能以工件为输入——活动可能要求使用工件；比如编码活动要参考《编码规范》。还有一种关系，工件既是活动的输入又是它的输出——活动修改工件；比如修改《编码规范》。
3.4、阶段和迭代：提供不同级别的决策时机
尽早解决重大风险，是软件工程管理中的一条重要原则。正如Tom Glib所说：“如果我们不主动化解风险，那么它们会自己找上门来。”[2]心存侥幸是很危险的。
RUP是风险驱动的。它将整个开发生命周期分为4个阶段：初始阶段、细化阶段、构造阶段、移交阶段。初始阶段着重化解业务风险，并确保所有涉众对项目达成一致的认识。细化阶段主要化解技术风险，要定义并创建可执行的系统架构。相对而言，当决定开始构造阶段的时候，风险已经比较小了。当然，风险是动态变化的，构造阶段和移交阶段照样会有这样那样的风险存在。
RUP的每个阶段又可分为一到多个迭代周期。采用迭代式开发，意味着有持续不断的反馈；反馈是决策的基础，也是化解风险的基础。迭代式开发的一个主要目的就是尽早降低风险，通过每次迭代中分析、按重要性排序并解决主要风险，来达到尽早化解风险的目的。
这个根据持续反馈来进行决策的时机，叫做里程碑（milestone）。里程碑有2种，阶段结束对应的里程碑叫做主要里程碑（major milestone）；迭代结束对应的里程碑叫做次要里程碑（minor milestone）。可以说，阶段和迭代，为开发团队提供了不同级别的决策时机。
上图清晰的表达了上述分析的思想。里程碑分为主要里程碑和次要里程碑2种；阶段可以包含多次迭代；每个阶段必然有一个主要里程碑标识结束，每个迭代必然以一个次要里程碑标识结束。
迭代的具体进行，是要靠角色执行相关活动。上图中的迭代和活动的多对多关系，精彩地反映了迭代开发的特点——每次迭代都执行多个（甚至全部）开发活动。
3.5、配置和变更管理支持迭代式的基于基线的开发
迭代式开发意味着每个后继迭代，都以前一个迭代为基础，不断地进化和完善系统，直至完成最终产品。历史上有一段时期，为了强调这一点，RUP曾特意宣传“迭代和增量开发”。
建立并管理基线（baseline），为迭代式开发提供了有力支持。基线的要点有二：一是要通过评审，二是要受配置和变更管理控制。IEEE对于基线的完整定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。
配置和变更管理完成建立并管理基线的任务。置于配置和变更管理之下的工件，称为配置项（configuration item）——因此下图把配置项建模为工件的子类。而基线就是有多个配置项组成的瞬时快照——因为受配置和变更管理控制是基线的必要条件。
上面讨论了“工件－配置项－基线”这些静态概念，下面再讨论一下相关动态概念。任何工件，都有可能发生变更；正如并不是所有工件都是配置项一样，变更也不一定都受控，比如，用于讨论的临时设计就不必受控。只有配置项的变更，才是需要受配置和变更管理控制的。到底哪些工件应当受控，是根据实践情况决定的，应当在规范性和灵活性之间权衡考虑。
3.6、发布是什么，发布不是什么
发布（release）是软件产品的一个稳定的、可执行的版本，它包括了发布说明、用户手册等相关工件。
单纯的文档或者不能执行的软件版本，并不是发布。
发布是某个迭代周期的成果，但是并非每个迭代周期都用发布。
图中表达得很明白，发布是特殊的基线。这意味着发布不是单一的工件，而是工件集；而且发布的工件都应当置于配置管理的控制之下，这是因为你必须标识和跟踪这些工件，开发团队或者用户的很多活动都和它们相关。
4、总结
UML已经广泛用于软件开发活动，可视化表达使得理解和解决问题变得容易。本文是UML的另一个应用，它被用来明确概念之间的关系，希望对大家有所启发。
