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

1. 緒論 

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

2. 軟體過程和敏捷建模

經典軟體工程理論所闡述的軟體過程，特別是瀑布模型，由於其較強的理想化環境條件假設，所以如果在實際軟體開發專案中採用，往往會與實際情況產生較大脫節，使得實施效果大打折扣，故而往往只以具有理論參考意義的面孔出現。而當前在業界，既有完整理論，又有較強可操作性的軟體過程，則以統一過程（the Unified 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條核心原則和13條核心實踐，筆者認為，體現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 Enterprise 8.0，DBMS為Oracle9i Enterprise for linux。
(2）中間層：執行在人行結算中心的應用伺服器上，OS為TurboLinux Enterprise 8.0，用C++語言實現了核心商業服務，開發工具選用Borland C++BuilderX 1.0 Enterprise。
(3）表示層：執行在各商業銀行的PC前端機（SCO UNIX 5.05平臺，270臺）及人行結算中心的PC前端機（Win2000/RedflagLinux4.0平臺，5臺）上。商行前端程式用C語言實現；人行前端程式用JAVA語言實現，開發工具選用Borland JBuilder 7 Enterprise。
    上述三個層次分別安裝了東方通科技公司的訊息中介軟體TongEASY 4.5 for Linux/SCO UNIX/Windows，整個系統的事務處理功能即由它保證。TongEASY作為一個基於三層C/S體系結構的中介軟體，其構成的交易管理平臺提供了交易管理、負載均衡、應用排程等功能。其包含的通訊管理模組還提供了可靠的資料傳輸、網路監控、流量控制等功能。

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

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

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

    這一實踐體現了“快速迭?蠢　鋇木?瘛Ｌ???竅低車幕?救砑??灘捎肦UP。按照Rational公司對UP的定義，軟體開發的生命週期被劃分為初始、細化、構造、交付四個階段，每個階段結束於定義良好的里程碑――即某些關鍵決策必須做出的時間點。為了更好地控制變更、減少開發風險，太原同城系統的開發遵循了RUP所規定的從一個迭代過程到下一個迭代過程的遞增式增長，從而形成了最終系統。具體而言，這些迭代過程包括：
(1）第一次迭代（歷時一個半月）：
    跨越UP所定義的初始階段。該次迭代實現的UP規程主要包括：初步業務建模、捕獲業務需求、建立開發環境等。通過該次迭代，完成了架構方案的確定，實現了部分子系統中最關鍵的業務用例的分析設計與編碼、測試――比如票據傳送、票據接收、票據檔案生成等。同時，通過測試比較，專案組明確了系統的體系結構，即：立足於基於訊息中介軟體的三層C/S結構系統。此外，還根據上述體系結構的特點，確定了開發語言與開發工具。值得一提的是，該次迭代的初衷並非單純針對太原同城系統，但太原同城系統事實上成為了此次迭代過程的第一個受益者。
(2）第二次迭代（歷時兩個半月）：
    跨越了UP所定義的細化階段和構造階段。該次迭代實現的UP規程包括業務建模、需求分析、體系結構設計、編碼實現，它所包括的數次小的迭代過程分別側重於分析、設計和編碼實現。首先，通過本次迭代，基本完成了對所有概要級別用例、使用者級別用例及大部分子功能級別用例的分析，同時，還完成了類設計、基本資料靜態結構設計與資料動態流向設計。系統架構的整體搭建也在此階段完成。之後，在上述架構的基礎上實現了相應的編碼工作。
(3）第三次迭代（歷時兩個半月）：
    跨越了UP所定義的構造階段和移交階段。該次迭代實現的UP規程包括補充業務建模、補充需求分析、補充編碼實現、系統測試、執行和支援等。通過該次迭代，完成了對各級別用例的修改、補充，補充完善了各功能模組的程式碼，完成了系統測試和部署準備。

當然，系統最終迭代次數的變更結果取決於太原同城系統的實際部署效果和部署後使用者的意見反饋。
同時，系統在進行某一階段的建模工作時，還注意儘量避免在該階段只專注於一個製品的製作。比如，在用例建模階段，還同時進行了使用者介面原型的設計工作；在資料建模階段，還將設計會議包括進來。

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

    太原同城系統的過程控制實踐很注重改造系統啟動時組織內部因沿襲UP思維方式而可能存在的不符合AM原則的文化障礙。比如，根據AM“多種模型建模”的精神，太原同城系統的建模過程就沒有受限於UML規定的若干建模製品。
    雖然UML定義了一系列的建模製品，但很顯然，完整建立其定義的所有建模製品是沒有必要的。另一方面，UML建模製品至少在分析需求時並不完備，也存在盲點。比如，UML無法滿足使用者介面建模需求、UML的活動圖無法描述一個資訊儲存的位置資訊等等。因此，在太原同城系統的開發中對UML製品根據需要進行了取捨。針對UML建模製品的不足，還補充了其它一些製品，包括一些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. 總結 

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408746/，如需轉載，請註明出處，否則將追究法律責任。