kapok

  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的另一個應用，它被用來明確概念之間的關系，希望對大家有所啟發。

  參考文獻：
  [1] Gary Pollice等著，宋銳等譯. 小型團隊軟件開發：以RUP為中心的方法. 中國電力出版社，2004
  [2] Per Kroll等著，徐正生等譯. Rational統一過程：實踐者指南. 中國電力出版社，2004

  作者簡介：
  溫昱，架構設計師，松耦合空間（http://lcspace.nease.net）創辦人。擅長面向對象、架構和框架設計，對設計模式、UML和軟件工程有深入研究。可以通過wenyu@china.com和作者聯系。