敏捷建模對統一過程的改造實踐[轉]

摘 要

摘要內容

    本文以山西省太原市人民銀行同城票據清算系統v2.0（簡稱“太原同城系統”
）開發中的軟件過程控制爲例，說明了作者(該系統項目經理)利用敏捷建模原則和
實踐改造統一過程軟件開發項目的若干體會。

優良的軟件過程可以爲開發高質量的軟件提供有效的實踐方案。當前在業界，既有
完整的理論，又有較強可操作性的軟件過程，則以統一過程（UP）和極限編程(XP)
最爲令人矚目。敏捷建模(AM)所倡導的一系列實踐中有許多做法與UP的實踐是不謀
而合的，有的情況則加強或改進了UP的某些實踐。通過總結AM的一系列實踐，作者
認爲，實踐以下四條原則即可基本反映出AM的精髓：1.明確最終目標；2.簡化工作
過程；3.快速迭代反饋；4.多種模型建模。爲此，作者以其中第二和第三條原則爲
重點，詳細介紹了以UP爲基本軟件過程的太原同城系統使用AM，提高開發敏捷性的
成功經驗。比如，在對第二條原則的實踐介紹中，描述了系統的迭代劃分情況；在
對第三條原則的實踐介紹中，描述了系統分析設計中有關製品，包括一些獨創性的
製品的製作經驗。

    關鍵詞：敏捷建模、統一過程、改造、太原同城

1. 緒論

    優良的軟件過程可以爲開發高質量的軟件提供有效的實踐方案。隨着軟件開發
複雜性的日益增強及軟件行業規範化管理經驗的逐漸積累，通過依託某種軟件過程
在開發中產生恰當製品、科學有效地控制開發節奏與步驟，從而合理調配與使用開
發資源、滿足開發願景，已經成爲提高軟件生產率、確保如期按質地提交軟件成果
的重要途徑，而這一觀念也正被越來越多的軟件開發公司所認同和採用。

2. 軟件過程和敏捷建模

    經典軟件工程理論所闡述的軟件過程，特別是瀑布模型，由於其較強的理想化
環境條件假設，所以如果在實際軟件開發項目中採用，往往會與實際情況產生較大
脫節，使得實施效果大打折扣，故而往往只以具有理論參考意義的面孔出現。而當
前在業界，既有完整理論，又有較強可操作性的軟件過程，則以統一過程（the Un
ified Process,簡稱UP）和極限編程（the eXtreme Programming,簡稱XP）最爲令
人矚目。

2.1 統一過程與極限編程及其思想觀念

2.1.1 UP與XP的特徵

    統一過程作爲一種重量級的指導性的軟件過程，其基本特徵體現在用例驅動、
以架構爲中心、迭代和增量開發等幾方面。根據對統一過程生命週期的不同劃分方
法，統一過程還分爲企業統一過程（EUP）、Rational統一過程（RUP）等不同子類
型。而極限編程則不同於統一過程，它在本質上屬於更爲敏捷的一種軟件過程，並
由一系列簡單卻互爲補充的實踐所組成。

2.1.2 統一過程的優勢

    雖然比較XP而言，UP更爲傳統一些，其過程控制靈活度也相對較弱，但由於這
種軟件過程非常適用於複雜、需求多變、開發難度大的情況，同時也可以根據項目
特點進行適當裁剪，所以仍然被許多軟件企業所廣泛採用。特別是，對於一些在軟
件過程控制方面依據UP原則已經形成較爲固定模式、同時又注重以各階段的指定製
品控制開發節奏的公司而言，如何在保持UP基本方法的前提下，提高UP項目開發的
敏捷性則是一個非常現實而重要的課題。

2.2 以敏捷建模改造統一過程的可行性

2.1.3 敏捷建模與統一過程在實踐中的內在聯繫

    事實上，敏捷建模（Agile Modeling，簡稱AM）所倡導的一系列實踐中有許多
做法與UP的實踐是不謀而合的，有的還加強或改進了UP的某些實踐。比如：

    UP和AM都強調“項目關係人積極參與”的重要意義，甚至允許項目關係人參與
建模。

UP和AM都強調“用代碼驗證”、“並行創建多個模型”。即使是UP，在必要情況下
也可調整決定同時執行源於不同規程的活動。

    UP和AM都遵循“增量建模”的實踐，但AM通過減小增量的幅度，改善了UP的迭
代實踐。

    AM“有危害時才更新模型”的實踐改進了UP及時同步各階段不同製品的要求。


    AM“使用合適的製品”的實踐改進了UP對UML建模製品的過分依賴。

    AM“集體所有”的實踐改進了UP項目中有關配置管理的觀念，通過營造開放、
交流的團隊文化，使所有項目成員都能訪問和修改各自想處理的製品，包括模型和
文檔。

    AM“使用最簡單的工具”的實踐拓展了UP只注重使用CASE工具的侷限。

2.1.4 實踐敏捷建模的主要原則

    與UP、XP相比，AM本身則是一種基於實踐的、不完整的、有序與混亂並存的軟
件過程。通常，軟件的開發可將UP、XP等作爲基礎軟件過程，用AM增強這些更加完
整的軟件過程。

    AM的概念吸收了敏捷開發聯盟（Agile Software Development Alliance）所倡
導的若干原則（限於篇幅，這些條款將不在文中詳述），並形成了自己的一系列原
則與實踐。縱觀AM論壇發起人Scott W. Ambler所提出的涉及AM的11條核心原則和1
3條核心實踐，筆者認爲，體現AM精髓的原則主要集中在如下幾個方面：

(1）明確最終目標：即軟件本身才是應當確保的工作目標；

(2）快速迭代反饋：明確各階段問題焦點，快速修訂前一階段過程中的製品，並推
回後一階段；

(3）多種模型建模：即要勇於突破傳統軟件過程所規定的建模工具的約束，根據效
果特點採用適用的建模模型描述軟件；

(4）簡化工作過程：任何階段都要以最簡單的解決方案來達至工作目標，不要追求
形式、不要過度構建軟件。

    雖然按照Ambler的觀點，必須完全執行所有11條核心原則和13條核心實踐才能
算得上是在敏捷建模，但筆者認爲，由於AM本身就是一種不完整的軟件過程，況且
AM本身必定會在行業實踐中進一步得到充實，所以可以認爲，在目前階段，實踐上
面總結出來的四條原則即可基本反映出AM的精髓。

3. 太原同城系統開發中的敏捷建模實踐

    在上述方針的指導下，可以利用敏捷建模對統一過程施行改造。以下將以山西
省太原市人民銀行同城票據清算系統v2.0（以下簡稱“太原同城系統”）爲例，說
明應用AM原則與實踐在改造一個UP開發項目過程中的一些體會。

3.1太原同城清算系統介紹

3.1.1開發背景

    太原同城系統是在金融體制改革的形勢下，由北京市泰通電子技術公司承擔開
發的，在太原市轄區範圍內建設的一個連接該市各個商業銀行和與人民銀行清算中
心的票據實時清算系統。通過實時處理貸記、借記票據交換業務，可以改變傳統的
票據手工交換方式，以電子流代替票據流，使資金可即時抵用，爲各商業銀行提供
統一、快捷、安全、可靠的資金清算渠道，也爲人民銀行提供了監控資金流量與流
向的現代化手段。

3.1.2系統體系結構

    太原同城系統是一個基於交易中間件、複合平臺、多語言聯合開發的三層C/S結
構系統。其三層架構分別爲：

(1）數據層：運行在人行結算中心的數據庫服務器上，OS爲TurboLinux Enterpris
e 8.0，DBMS爲Oracle9i Enterprise for linux。

(2）中間層：運行在人行結算中心的應用服務器上，OS爲TurboLinux Enterprise
8.0，用C++語言實現了核心商業服務，開發工具選用Borland C++BuilderX 1.0 En
terprise。

(3）表示層：運行在各商業銀行的PC前端機（SCO UNIX 5.05平臺，270臺）及人行
結算中心的PC前端機（Win2000/RedflagLinux4.0平臺，5臺）上。商行前端程序用
C語言實現；人行前端程序用JAVA語言實現，開發工具選用Borland JBuilder 7 En
terprise。

    上述三個層次分別安裝了東方通科技公司的消息中間件TongEASY 4.5 for Lin
ux/SCO UNIX/Windows，整個系統的事務處理功能即由它保證。TongEASY作爲一個基
於三層C/S體系結構的中間件，其構成的交易管理平臺提供了交易管理、負載均衡、
應用調度等功能。其包含的通訊管理模塊還提供了可靠的數據傳輸、網絡監控、流
量控制等功能。

3.2太原同城系統開發中的敏捷建模實踐

    本人作爲太原同城系統的項目經理，按照上文所述觀點，將敏捷實踐中“明確
最終目標、快速迭代反饋、多種模型建模、簡化工作過程”這四方面的內容與實際
開發的過程控制進行了結合。以下是對其中這幾方面實踐內容的總結。

3.2.1太原同城系統的快速迭代與增量式開發實踐

    這一實踐體現了“快速迭代反饋”的精神。太原同城系統的基本軟件過程採用
RUP。按照Rational公司對UP的定義，軟件開發的生命週期被劃分爲初始、細化、構
造、交付四個階段，每個階段結束於定義良好的里程碑――即某些關鍵決策必須做
出的時間點。爲了更好地控制變更、減少開發風險，太原同城系統的開發遵循了RU
P所規定的從一個迭代過程到下一個迭代過程的遞增式增長，從而形成了最終系統。
具體而言，這些迭代過程包括：

(1）第一次迭代（歷時一個半月）：

    跨越UP所定義的初始階段。該次迭代實現的UP規程主要包括：初步業務建模、
捕獲業務需求、建立開發環境等。通過該次迭代，完成了架構方案的確定，實現了
部分子系統中最關鍵的業務用例的分析設計與編碼、測試――比如票據發送、票據
接收、票據文件生成等。同時，通過測試比較，項目組明確了系統的體系結構，即
：立足於基於消息中間件的三層C/S結構系統。此外，還根據上述體系結構的特點，
確定了開發語言與開發工具。值得一提的是，該次迭代的初衷並非單純針對太原同
城系統，但太原同城系統事實上成爲了此次迭代過程的第一個受益者。

(2）第二次迭代（歷時兩個半月）：

    跨越了UP所定義的細化階段和構造階段。該次迭代實現的UP規程包括業務建模
、需求分析、體系結構設計、編碼實現，它所包括的數次小的迭代過程分別側重於
分析、設計和編碼實現。首先，通過本次迭代，基本完成了對所有概要級別用例、
用戶級別用例及大部分子功能級別用例的分析，同時，還完成了類設計、基本數據
靜態結構設計與數據動態流向設計。系統架構的整體搭建也在此階段完成。之後，
在上述架構的基礎上實現了相應的編碼工作。

(3）第三次迭代（歷時兩個半月）：

    跨越了UP所定義的構造階段和移交階段。該次迭代實現的UP規程包括補充業務
建模、補充需求分析、補充編碼實現、系統測試、運行和支持等。通過該次迭代，
完成了對各級別用例的修改、補充，補充完善了各功能模塊的代碼，完成了系統測
試和部署準備。

    當然，系統最終迭代次數的變更結果取決於太原同城系統的實際部署效果和部
署後用戶的意見反饋。

同時，系統在進行某一階段的建模工作時，還注意儘量避免在該階段只專注於一個
製品的製作。比如，在用例建模階段，還同時進行了用戶界面原型的設計工作；在
數據建模階段，還將設計會議包括進來。

3.2.2太原同城系統的多種模型建模實踐

    太原同城系統的過程控制實踐很注重改造系統啓動時組織內部因沿襲UP思維方
式而可能存在的不符合AM原則的文化障礙。比如，根據AM“多種模型建模”的精神
，太原同城系統的建模過程就沒有受限於UML規定的若干建模製品。

    雖然UML定義了一系列的建模製品，但很顯然，完整創建其定義的所有建模製品
是沒有必要的。另一方面，UML建模製品至少在分析需求時並不完備，也存在盲點。
比如，UML無法滿足用戶界面建模需求、UML的活動圖無法描述一個信息存儲的位置
信息等等。因此，在太原同城系統的開發中對UML製品根據需要進行了取捨。針對U
ML建模製品的不足，還補充了其它一些製品，包括一些UML問世之前就存在了的建模
製品（如數據流圖），甚至包括一些有獨創性的建模製品（如數據流向設計）。下
面是太原同城系統分析設計過程中一些製品的製作情況描述：

⑴ 編寫有效用例，透徹描述和分解需求規格說明書中提出的各項功能需求。

比如，對於“中心日初始化”這一功能而言，我們需要清楚地說明人行結算中心在
每個工作日業務開始時，日初始化功能涉及到的主執行者、目標、前置條件、觸發
條件、主要場景、意外情況處理等細節情況。其有效用例主要部分摘要如下：

“中心日初始化”處理用例

n 主執行者：人行結算中心繫統管理員

n 語境中的目標：人行結算中心繫統能開始處理稅票信息。

n 級別：用戶目標。

n 項目相關人員和利益：

1. 人行結算中心操作員

2. 人行結算中心業務領導

3. 人行結算中心

n 前置條件：人行結算中心操作員、系統管理員或業務領導登錄成功。

n 觸發事件：人行結算中心繫統工作人員登錄成功後開設新工作日。

n 成功保證：人行結算中心新工作日開設成功，並且工作狀態進入日間狀態。

n 最小保證：人行結算中心繫統工作人員登錄驗證。

n 主成功場景：

1. 人行結算中心前一工作日日終判斷。

2. 人行結算中心本工作日日初註冊：人行結算中心繫統獲取新的工作日日期；人行
結算中心該工作日由日初狀態進入日間狀態。

n 擴展：

*a. 任意時刻，系統崩潰：（略）

*b. 任意時刻，網絡連通出現故障：（略）

1a. 結算中心前一工作日日終尚未完成：

繼續進行結算中心前一工作日日終處理，直到日終成功。

1b. 結算中心前一工作日日終已經完成。

繼續進行新一工作日的日初處理。

2. 手工輸入的新工作日日期不符合要求：提示修改工作日日期，直到合格。

n 使用頻率：每個工作日一次

    太原同城系統中包括上述用例在內所有用例的設計，其設計風格都與Alistair
Cockburn在《Writing Effective Use Cases》一書中推薦的風格相同。其中，下
橫線部分是準備繼續擴展描述的下一級用例，爲省篇幅本文從略。

    這裏，應當突破UP聲稱的對用例的認識侷限，意識到用例並不足以驅動所有事
情。事實上，用例只是全部需求，甚至只是全部功能需求的一部分，對諸如用戶界
面需求、商務規則、非功能需求的描述，僅靠系統用例是不夠的，有必要以基本界
面原型、界面流程圖、CRC卡等加以補充。

⑵ 針對“概要級別用例”、“用戶級別用例”及“子功能級別用例”使用數據流圖
進行逐層分析，瞭解各用例所涉及的數據源點與匯點之間的關係。

    通過數據流分析這種傳統的分析手段，我們可以彙總出數據字典，並作爲靜態
數據結構設計的依據。下面的數據流圖實例就是太原同城系統中針對用戶級別用例
――“實時提出”所做的分析。依託數據流圖，“實時提出”功能所涉及到的各個
數據存儲、各個數據源點和終點、各個加工都一目瞭然。

⑶ 根據數據流圖進行數據建模。

    在UML中，數據模型並沒有很好的建模製品進行表達，但我們有必要提供數據模
型製品，併爲後面諸如數據庫表靜態結構設計、UML類圖設計等工作做準備。以下展
示的，就是人行結算中心數據建模工作的一小部分結果。

    項目組爲完成該項設計，專門召集了數據建模會議。會議方式是項目經理組織
全體項目成員集體討論，集思廣益。最終討論結果以PowerDesigner爲數據建模工具
當場記錄和修改，主要涉及庫表結構定義、各數據項定義、表間關係定義、主外鍵
定義等內容。不論是在當時的建模會議上，還是以後進行修改時，PowerDesigner在
對數據建模結果進行快速修正和記錄方面都體現了強大的功能。

⑷ 參照靜態數據結構、數據流圖、用例描述獲得數據流向設計圖。

    這一獨創的製品具有與UML時序圖異曲同工的效果。但如此表達更符合程序員的
編碼習慣，更有利於實現從僞代碼到真實代碼的轉化。至於設計範圍，主要依據用
例描述來確定。以下是“中心日初始化”這一子功能級別用例的數據流向設計實例
：

“中心日初始化”數據流向

查詢系統運行控制表

if 有記錄

{

定位到工作日期最晚的一條記錄

if 工作狀態 <> 0<日終>

{

退出日初始化處理

}

手工選擇工作日期 ××××-××-××

判斷該日的記錄是否已經存在

if 存在

{

提示並退出日初處理

}

判斷該日是否小於庫中的最大日期

if 小於

{

提示並退出日初處理

}

    在系統運行控制表寫入一條記錄（手工選擇工作日期 ××××-××-××工作
狀態1<日初>；工作場次1；是否平帳0<未清算>）

    清空業務庫表：網點日提出票據表、網點日提入票據表、網點日提入錯誤票據
表、網點磁盤日待提入票據表、網點磁盤日提入登記表、網點日清算表、清算行日
清算表、管轄行日清算表、清算帳戶日清算表

更新網點狀態權限表所有記錄的網點日對帳標記爲0<未對帳>，提入流水號爲1

更新網點統計監控表所有記錄的提出筆數、清分筆數、提入筆數、出錯筆數爲0；場
次爲1；通信狀態爲0<斷開>

    行號表是否需更新：

    從版本控制表中查詢>當前行號表版本號的記錄，如果有記錄，依次判斷該記錄
的生效日期是否到期

if 有到期記錄

{

備份當前行號表到備份行號表

更新行號表

更新網點狀態權限表、網點統計監控表

修改系統運行控制表的當前行號表版本號

}

    在系統運行控制表中修改記錄（工作日期 ××××-××-××工作狀態2<日間
>；工作場次1；是否平帳0<未清算>）

}

else

{

手工選擇工作日期 ××××-××-××

    在系統運行控制表寫入一條記錄（手工選擇工作日期 ××××-××-××工作
狀態2<日間>；工作場次1；是否平帳0<未清算>）

}

    在數據流向設計中，總的設計方式是參照流程順序和時間順序。其中，橫線部
分是此製品涉及到的數據庫表。對相應庫表的重要改動內容也同時記錄在旁邊，狀
態字段的內容改動其含義記錄在“< >”中。

可見，通過上述各環節的分析設計工作，系統的製品已大大突破了UML所定義的製品
範圍。雖然這其中所完成的基本界面原型設計、界面流程圖等製品尚未加以羅列，
事實上其存在與製作對於系統的透徹分析是很有必要的。

3.2.3太原同城系統的簡單化和目標明確化實踐

    當然，太原同城系統的開發實踐還注意了“簡化工作過程”與“明確最終目標
”這兩項AM精神的貫徹。比如，建造製品時對UML明確定義的部分製品的捨棄、在類
圖的製作過程中僅着重核心類的建模、在各階段建模過程中注意點到爲止，使製品
量與其對開發的指導價值相匹配……等等，都體現了簡單化的用意。而所有這一切
，其實都是爲完成最終目標――目標軟件本身而服務的。

筆者認爲，這兩方面的實踐雖然相對更加哲學化、抽象化一些，但在開發過程控制
中依舊要始終加以留意，使之真正起到指導思想的作用。

4. 總結

    綜上所述，對於統一過程而言，敏捷建模是在保持統一過程原有基本優點的前
提下，加強這一重量級軟件過程敏捷程度的有效途徑。相信，會有越來越多的統一
過程軟件開發實踐將受益於對敏捷建模精髓的汲取，而太原同城系統開發的成功實
踐就是其中一個很好的例子。

參考書目

1 Ivar Jacobson等.《統一軟件開發過程》.第1版.《機械工業出版社》, 2002年1
月：第一部分P1-81

2 Alistair Cockburn.《編寫有效用例》.第1版. 《機械工業出版社》,2002年9月
:全書

3 Geri Schneider等.《用例分析技術》.第1版. 《機械工業出版社》,2002年8月:
全書

4 Ambler,S.W. 《敏捷建模－極限編程和統一過程的有效實踐》.第1版.《機械工業
出版社》，2003年4月：全書

5 John W.Satzinger《系統分析與設計》.第1版.《機械工業出版社》，2002年8月
:第5章P125-158,第6章P167-210