一圖勝千言：RUP核心概念解析
原創作者：wakeful
轉載請註明：來自Sawin系統分析之窗
最後修改時間：2005-2-22
一圖勝千言：RUP核心概念解析
溫 昱
本文以發表於軟件過程專家網www.51cmm.com
在實踐中，筆者發現，對概念的理解不到位，特別是對概念之間的關係理解不到位，是阻礙不少人成功應用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的另一個應用，它被用來明確概念之間的關係，希望對大家有所啓發。
參考文獻：
[1] Gary Pollice等著，宋銳等譯. 小型團隊軟件開發：以RUP爲中心的方法. 中國電力出版社，2004
[2] Per Kroll等著，徐正生等譯. Rational統一過程：實踐者指南. 中國電力出版社，2004
【作者介紹】 wakeful
溫昱，架構設計師，資深諮詢顧問，松耦合空間（http://lcspace.nease.net）創辦人。擅長面向對象、架構和框架設計，對設計模式、UML和軟件工程有深入研究。
作者Email地址：[email protected]