kapok

  1、弄清概念的必要性
  隨著軟件學(xué)科和軟件業(yè)的不斷發(fā)展，“名詞”越來越多。但是，“名詞”背后的“含義”也真的有如此之多的增長嗎？
  舉個例子。1986年，Barry Boehm提出了軟件開發(fā)的螺旋模型。從那時起，螺旋模型被當作軟件開發(fā)的標準方法。螺旋模型還有其他不同的常用名字，比如演進模型，或者迭代模型[1]。類似的例子還有很多。
  看來，軟件界存在不少這種“新瓶裝舊酒”的現(xiàn)象——一個新名詞出現(xiàn)了，它可能僅僅是披著新的表達形式的外衣，而其含義其實和某個舊名詞相同。
筆者認為，在軟件學(xué)科飛速發(fā)展的今天，反而是踏踏實實搞清楚“變幻無窮”的諸多名詞背后的真正含義，才是最便捷之道。

  2、本文的方法：一圖勝千言
  本文采用“為概念及其關(guān)系建模”這樣一種方法，不僅考察單個名詞的含義，還考察名詞之間的關(guān)系。
  一圖勝千言。一個概念的本質(zhì)，往往需要從它同其他概念的關(guān)系中，得以體現(xiàn)。不僅考察個體，還考察多個個體之間的關(guān)系，這種方法在系統(tǒng)論中，被比喻成“1 + 1 > 2”。令人愉快的是硬幣的另一面，注重考察關(guān)系這種方法，從其成本角度而言卻是“1 + 1 < 2”。

  3、RUP核心概念解析
  3.1、任務(wù)來自問題
  RUP著名的二維結(jié)構(gòu)，其時間維相關(guān)的概念有階段、迭代、里程碑等，內(nèi)容維相關(guān)概念有工作流、角色、活動、工件等。但筆者發(fā)現(xiàn)，不少人對這些概念理解不深，特別是對概念之間的關(guān)系把握不到位，造成實踐中出現(xiàn)問題。

  另外，就是迭代式開發(fā)——這種包括RUP在內(nèi)的多種軟件工程過程都一致推崇的最佳實踐——和活動、工件這些基本概念有何關(guān)系。不知道迭代和活動、工件的關(guān)系，實際應(yīng)用RUP時又如何貫徹迭代式開發(fā)的思想呢？
  還有，配置和變更管理對所有現(xiàn)代軟件開發(fā)過程都是必不可少的支持活動，RUP更是將其列為“RUP的6大最佳實踐”之一。但筆者發(fā)現(xiàn)，不少開發(fā)人員認為配置和變更管理太麻煩，僅僅是因為他們沒有理解配置和變更管理和工件的基本關(guān)系。
我們的任務(wù)，就來自于這些問題。我可以用一幅圖解決這些問題嗎？

  3.2、一圖勝千言
  下圖是一幅UML類圖，它概括了上述問題的相關(guān)概念，并著重表達了概念之間的關(guān)系。本圖的豐富語義，我們通過下面幾節(jié)細細來分析。

  3.3、角色執(zhí)行活動，活動生產(chǎn)工件
  任何軟件工程過程，都少不了角色（role）、活動（activity）、工件（artifact）等概念（或者類似概念）。

  這些概念本身很好理解。角色是對個人或者作為開發(fā)團隊的一組人的職責(zé)的規(guī)定；具體人和角色的關(guān)系，好比人和帽子的關(guān)系。活動就是角色執(zhí)行的工作單元。工件就是工作的成品或半成品。
  倒是這些概念的關(guān)系顯得更加重要。角色的職責(zé)，具體體現(xiàn)在他執(zhí)行活動和負責(zé)工件上。工件是由活動生產(chǎn)出來的——工件是活動的輸出；比如制定《編碼規(guī)范》。然而，活動本身也可能以工件為輸入——活動可能要求使用工件；比如編碼活動要參考《編碼規(guī)范》。還有一種關(guān)系，工件既是活動的輸入又是它的輸出——活動修改工件；比如修改《編碼規(guī)范》。

  3.4、階段和迭代：提供不同級別的決策時機
  盡早解決重大風(fēng)險，是軟件工程管理中的一條重要原則。正如Tom Glib所說：“如果我們不主動化解風(fēng)險，那么它們會自己找上門來。”[2]心存僥幸是很危險的。
  RUP是風(fēng)險驅(qū)動的。它將整個開發(fā)生命周期分為4個階段：初始階段、細化階段、構(gòu)造階段、移交階段。初始階段著重化解業(yè)務(wù)風(fēng)險，并確保所有涉眾對項目達成一致的認識。細化階段主要化解技術(shù)風(fēng)險，要定義并創(chuàng)建可執(zhí)行的系統(tǒng)架構(gòu)。相對而言，當決定開始構(gòu)造階段的時候，風(fēng)險已經(jīng)比較小了。當然，風(fēng)險是動態(tài)變化的，構(gòu)造階段和移交階段照樣會有這樣那樣的風(fēng)險存在。

  RUP的每個階段又可分為一到多個迭代周期。采用迭代式開發(fā)，意味著有持續(xù)不斷的反饋；反饋是決策的基礎(chǔ)，也是化解風(fēng)險的基礎(chǔ)。迭代式開發(fā)的一個主要目的就是盡早降低風(fēng)險，通過每次迭代中分析、按重要性排序并解決主要風(fēng)險，來達到盡早化解風(fēng)險的目的。

  這個根據(jù)持續(xù)反饋來進行決策的時機，叫做里程碑（milestone）。里程碑有2種，階段結(jié)束對應(yīng)的里程碑叫做主要里程碑（major milestone）；迭代結(jié)束對應(yīng)的里程碑叫做次要里程碑（minor milestone）。可以說，階段和迭代，為開發(fā)團隊提供了不同級別的決策時機。

  上圖清晰的表達了上述分析的思想。里程碑分為主要里程碑和次要里程碑2種；階段可以包含多次迭代；每個階段必然有一個主要里程碑標識結(jié)束，每個迭代必然以一個次要里程碑標識結(jié)束。
  迭代的具體進行，是要靠角色執(zhí)行相關(guān)活動。上圖中的迭代和活動的多對多關(guān)系，精彩地反映了迭代開發(fā)的特點——每次迭代都執(zhí)行多個（甚至全部）開發(fā)活動。

  3.5、配置和變更管理支持迭代式的基于基線的開發(fā)
  迭代式開發(fā)意味著每個后繼迭代，都以前一個迭代為基礎(chǔ)，不斷地進化和完善系統(tǒng)，直至完成最終產(chǎn)品。歷史上有一段時期，為了強調(diào)這一點，RUP曾特意宣傳“迭代和增量開發(fā)”。
  建立并管理基線（baseline），為迭代式開發(fā)提供了有力支持。基線的要點有二：一是要通過評審，二是要受配置和變更管理控制。IEEE對于基線的完整定義是：已經(jīng)通過正式復(fù)審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎(chǔ)，并且只能通過正式的變更控制過程進行改變。
  配置和變更管理完成建立并管理基線的任務(wù)。置于配置和變更管理之下的工件，稱為配置項（configuration item）——因此下圖把配置項建模為工件的子類。而基線就是有多個配置項組成的瞬時快照——因為受配置和變更管理控制是基線的必要條件。

  上面討論了“工件－配置項－基線”這些靜態(tài)概念，下面再討論一下相關(guān)動態(tài)概念。任何工件，都有可能發(fā)生變更；正如并不是所有工件都是配置項一樣，變更也不一定都受控，比如，用于討論的臨時設(shè)計就不必受控。只有配置項的變更，才是需要受配置和變更管理控制的。到底哪些工件應(yīng)當受控，是根據(jù)實踐情況決定的，應(yīng)當在規(guī)范性和靈活性之間權(quán)衡考慮。

  3.6、發(fā)布是什么，發(fā)布不是什么
  發(fā)布（release）是軟件產(chǎn)品的一個穩(wěn)定的、可執(zhí)行的版本，它包括了發(fā)布說明、用戶手冊等相關(guān)工件。
  單純的文檔或者不能執(zhí)行的軟件版本，并不是發(fā)布。
  發(fā)布是某個迭代周期的成果，但是并非每個迭代周期都用發(fā)布。
  圖中表達得很明白，發(fā)布是特殊的基線。這意味著發(fā)布不是單一的工件，而是工件集；而且發(fā)布的工件都應(yīng)當置于配置管理的控制之下，這是因為你必須標識和跟蹤這些工件，開發(fā)團隊或者用戶的很多活動都和它們相關(guān)。

  4、總結(jié)
  UML已經(jīng)廣泛用于軟件開發(fā)活動，可視化表達使得理解和解決問題變得容易。本文是UML的另一個應(yīng)用，它被用來明確概念之間的關(guān)系，希望對大家有所啟發(fā)。

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

  作者簡介：
  溫昱，架構(gòu)設(shè)計師，松耦合空間（http://lcspace.nease.net）創(chuàng)辦人。擅長面向?qū)ο蟆⒓軜?gòu)和框架設(shè)計，對設(shè)計模式、UML和軟件工程有深入研究。可以通過wenyu@china.com和作者聯(lián)系。